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This  report  describes  the  spec 
control  system  (DFCS)  software 
program  entitled  "Methods  for 
Flight  Control  Systems,"  as 
Modification  1.  The  intent 
demonstration  illustrative  of 
architecture.  Accordingly, 
applications  software  were 
channels . 


Foreword 

ification,  design,  and  testing  a  digital  flight 
that  has  been  prepared  under  an  FAA- sponsored 
the  Verification  and  Validation  of  Digital 
Subtask  4. 5. 2.1  of  Contract  NAS2-11853, 
has  been  to  conduct  an  N-version  programming 
DFCS  software  fault  tolerance  for  a  quadruplex 
four  independently  developed  versions  of 
coded  and  demonstrated  in  respective  DFCS 


Considerable  background  information  is  presented,  largely  of  a  system  or 
software  design  nature.  First,  higher  level  software  encompassing  the  In¬ 
version  software  is  described,  including  a  multitasking  test  harness  and  the 
foreground  executive  programs  for  the  four  DFCS  channels.  Coded  in  Ada  R 
the  interfaces  for  this  software  were  set  up  for  the  insertion  of  the  in¬ 
version  applications  modules  and  the  associated  software  voters.  These 
applications  modules  were  then  developed  in  accord  with  the  respective  DFCS 
program  unit  specifications. 

This  report  has  also  been  published  as  Lockheed-Georgia  Company  Engineering 
Report  LG86ER0163. 
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1 . 0  I.  TRODUCTION 

A  set  of  software  program  unit  specifications  was  generated  via  the  process 
depicted  in  Figure  1  for  use  in  an  exploratory  investigation  of  software 
fault  tolerance  using  the  N-version  programming  approach.  The  resultantly 
developed  software  is  representative  of  a  scaled-down  flight  control  system 
(see  Section  2.0)  with  a  critical  pitch-axis  fly-by-wire  (FBW)  function. 
Accordingly,  a  double  fail -operational ,  quadruplex  system  architecture  was 
postulated  to  furnish  requisite  system  reliability.  Each  of  the  four  DFCS 
channels,  moreover,  incorporated  a  different  version  of  applications  software 
as  independently  developed  by  a  different  programmer. 

The  overall  DFCS  software  structure,  or  the  multirate  executive  program  and 
its  called  procedure  interfaces,  however,  was  essentially  the  same  in  each 
channel  per  Section  4.0.  Each  DFCS  executive  contains  calls  to  N-version 
program  units,  which  in  turn  usually  include  calls  to  voters  for  cross¬ 
checking  the  intermediate  computations  of  all  the  channels.  Central  to  the 
N-version  demonstration,  these  program  units  were  developed  using  the  Ada 
programming  language  in  accordance  with  a  set  of  applications  software  module 
specifications,  which  are  presented  in  Sections  5.0  through  13.0. 

Each  of  the  program  units  was  constructed  so  that  it  could  be  run  in  a  single 
channel  test  harness  on  a  stand-alone  basis  for  unit  testing  and  de-bugging, 
or  as  part  of  the  total  program  for  integrated  4-version  testing.  The  latter 
entails  the  voting  of  the  four  versions  of  the  DFCS  software  running 
effectively  in  parallel  on  a  single  VAX  8650  for  the  N-version  software 
demonstration  and  evaluation.  Hence,  a  non-realime  multitasking  test 
executive  program  with  suitable  integral  test  drivers  was  devised  (see 
Section  14.0)  to  enable  convenient  software  integration  and  valid  N-version 
evaluation  testing. 

Figure  2  summarizes  the  organization  of  the  multitasking  test  harness,  where 
Ada  tasks  are  denoted  by  the  parallelogram  shaped  boxes.  Task  TEST_EXEC 
performs  or  directs  all  of  the  automated  test  functions,  such  as  input  test 
data  application  and  results  processing.  The  software  for  each  of  the  four 
DFCS  channels  runs  within  an  associated  DFCS_EXEC  task,  which  are  coordinated 
such  that  synchronization  occurs  at  each  software  voting  plane.  If  a  channel 
output  is  outside  of  permissible  limits,  it  is  assigned  the  voter  selected 
value  so  that  the  erroneous  state  is  not  propagated.  Note  that  the  DFCS_EXEC 
tasks  replace  the  top-level  flight  software,  which  is  not  germane  to  the 
problem  at  hand,  so  that  the  four  DFCS  channels  can  run  logicallv  in 
parallel . 


1.1  Software  Fault  Tolerance 

Concern  over  the  potential  for  generic  or  common-mode  software  faults  in 
critical  systems  has  prompted  rather  widespread  interest  within  the  aerospace 
industry  in  software  fault  tolerance.  While  the  enabling  technology  appears 
to  be  in  place,  it  remains  to  demonstrate  and  assess  all  aspects  of  fault- 
tolerant  software  for  critical  DFCS  applications.  Various  attributes  of  DFCS 
software,  moreover,  present  some  challenging  demands.  Temporal  constraints, 
such  as  difference  equation  iteration  rates  or  maximum  fault 
detection/recovery  times,  are  of  particular  concern. 
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- FOUR  INDEPENDENT  VERSIONS  OF  DFCS  SOFTWARE 


Figure  1  -  Project  Task  Flow  Diagram 


The  cwo  primary  approaches  to  fault  tolerance, 
recovery  blocks  (Ref.  1),  are  depicted  in  Figure  3. 
versions  of  software  performing  the  same  function(s 
version  software,  the  versions  must  be  developed  i 
logically  in  parallel,  and  the  version  outputs 
voter/comparator  for  selection  of  the  proper  res 
alternates  run  logically  in  a  sequence,  which  needs  to 
extent  that  alternate  versions  fail  their  accepcanc 
level  of  degradation  in  performance  is  accepted 
Alternates  to  ensure  continuing  operation. 


N-version  software  and 
Both  involve  dissimilar 
) .  In  the  case  of  N- 
ndependently .  They  run 
are  submitted  to  a 
ult.  Recovery  block 
be  invoked  only  to  the 
e  test.  Normally,  some 
with  among  successive 


Of  these  two  approaches,  N-version  holds  strong  appeal  for  most  types  of  DFCS 
software.  The  aforementioned  time  constraints  are  a  dominant  factor  in  such  a 
preference.  Hence,  the  DFCS  application  program  modules  under  this 
investigation,  were  implemented  using  the  N-version  method  .  As  suggested  in 
Figure  3,  the  voter/comparator  is  a  potential  single  point  of  failure  in  the 
N-version  approach.  As  a  consequence,  dissimilar  voters  are  sometimes  used 
to  obviate  this  prospect,  but  the  compounding  of  complexity  is  appreciable, 
so  only  single  voters  were  used  in  this  investigation 


As  with  all  software  fault  tolerance  development  efforts,  strong  emphasis  was 
placed  on  establishing  definitive,  high  quality  software  specifications 
(e.g.,  see  Ref. 2).  Completeness,  accuracy,  and  lack  of  ambiguity  are  in 
general  essential  to  the  realization  of  fault- tolerant  software,  so  the 


prospects  for  demonstrating  and  evaluating  N-version  software  are  crucially 
dependent  on  the  software  specifications.  For  example,  aspects  such  as 
maximum  time  allowances  for  voted  code  segments,  as  well  as  specific  modes 
and  responses  for  voting,  must  be  completely  and  precisely  stipulated 

Despite  all  initial  efforts,  some  deficiencies  existed  in  the  specifications. 
Their  rectification  was  rather  time-consuming,  but  the  variety  of  questions 
raised  by  different  programmers  did  force  corrections  to  the  specifications 
that  might  otherwise  might  not  have  been  so  thorough.  Simlarly,  software  de¬ 
bugging  was  facilitated  by  the  the  N-version  approach  Overall,  software 
fault  tolerance  has  some  drawbacks,  inherent  or  potential,  as  summarized  in 
Figure  4.  Still,  the  net  benefits  appear  worth  pursuing. 

1,2  Demonstration  Guidelines 

The  DFCS  demonstration  software  was  coded  using  DEC’s  Ada  compiler  for  the 
VAX  VMS  operating  system  at  the  Lockheed-Georgia  Company.  The  DFCS  software 
and  the  descriptions  in  this  memorandum  are  intended  to  be  essentially  in 
accord  with  DO-178A,  i.e.,  the  documentation  is  to  be  illustrative  of 

compliance  without  necessarily  being  exhaustive.  Configuration  control, 
error  logging,  and  delineation  of  software  development  phases  are  to  be 
observed  in  an  orderly  manner  that  supports  and  enhances  the  value  of  the 
results  of  the  investigation. 

The  following  assumptions  were  adopted  at  the  outset  to  expedite  but  in  no 
way  compromise,  the  conduct  of  the  investigation: 

o  No  Flight  Control  Computer  Operating  System 
o  No  Bus  Management  Software  Functions 
o  No  Hardware-Related  Instructions 
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o  Limited  Pitch  Axis  Functions  Only 

o  No  Fixed  Point  Arithmentic,  and  Hence  No  Variable  Scaling. 


After  program  unit  testing  and  de-bugging,  several  stages  of  testing  were 
conducted:  integration  and  demonstration  testing.  Due  to  specification 
discrepancies  detected  during  coding,  the  specification  parts  of  this 
document  were  revised  before  consistency  among  versions  was  established. 
Most  of  these  discrepancies  were  incompletely  or  incorrectly  specified  logic. 


1.3  Ada  Programming  Language 

There  are  strong  indications  that  the  Ada  programming  language  (Ref.  3)  will 
experience  widespread  usage  in  civil  aviation  in  the  near  term.  This  would 
be  based  primarily  on  the  merits  of  the  language  itself,  rather  than  on  the 
U.S.  Department  of  Defense's  influence.  Despite  its  drawbacks,  the  Ada 
programming  language  has  no  viable  competition  now  for  use  in  digital  flight 
system  applications.  Of  course,  the  language  is  still  developmental  with 
regard  to  support  of  flightworthy  computers,  but  the  associated  problems 
should  be  correctable  with  adequate  funding  from  military  programs.  Two 
particularly  significant  problems  associated  with  Ada  are  the  overhead  of 
tasking  and  machine  language  code  insertions.  Neither  factor  was  applicable 
to  the  problem  addressed  here.  Tasking  was  used  for  simulation  purposes,  but 
not  for  DFCS  software  per  se . 

Here  the  use  of  Ada  facilitated  the  conduct  of  the  N-version  software 
demonstration  by  enabling  explicit  definition  of  program  units  specification 
parts,  precise  definition  of  their  software  interfaces,  the  construction  of 
the  multitasking  test  harness,  and  non-interference  observation  of  test 
results  through  Ada  package  importation  by  test  units. 

Specification  benefits  naturally  derive  from  the  two-part  composition  of  Ada 
program  units,  which  involve  a  specification  part  and  a  corresponding  body 
->art.  The  intent  here  is  to  use  Ada  packages  and  procedure  specification 
parts  to  define  the  fault- tolerant  software  modules.  Each  specification  part 
defines  a  particular  interface  and  its  available  services,  and  is  refective 
of  and  consistent  with  the  overall  design  of  the  program.  Hence,  this 
document  includes  Ada  specification  parts  as  the  precise.  lower- level 
portions  of  the  respective  module  specifications.  The  N-version  programmers 
used  them  to  implement  the  DFCS  functions  and  services  in  the  associated  bodv 
parts  in  the  form  of  executable  Ada  code. 

Although  the  imposition  of  a  well-defined  program  design  tends  to  eliminate 
many  types  of  software  faults,  those  that  might  remain  would  seem  likelv  to 
be  more  restricted  to  chose  types  chat  are  detectable  bv  the  N-version 
software  voters.  This  would  obviously  be  desirable  from  both  experimental 
and  architectural  standpoints.  Note  that  the  Ada  specification  parts  are 
only  one  component  of  the  module  specifications;  English  text  and  analytical 
diagrams,  for  example,  were  used  as  well.  Follow-on  activities  will 
investigate  the  use  of  comments  expressed  in  the  Anna  (annotated  Ada) 
specification  langauge .  Logic  specification  checks  for  completeness  and  test 
case  generation  will  also  be  pursued. 


Anna  Specification  Language 


In  general,  formal  specification  has  been  identified  as  the  key  to 
rationalizing  the  software  development  process  (Ref.  4).  In  the  case  of 
fault-tolerant  software,  moreover,  formal  specification  would  seem  necessary 
to  eliminate  a  class  of  faults  that  cannot  be  tolerated,  namely  software 
faults  originating  in  specifications.  By  definition,  such  faults  lie  outside 
the  safeguards  of  software  fault  tolerance,  which  it  is  charged  with  ensuring 
specification  conformity  during  operation,  under  the  assumption  that  the 
specification  is  correct.  Thisproperty  can  be  affirmed  to  some  extent  by  the 
verifiability  inherent  in  formal  specifications. 

The  Anna  (annotated  Ada)  specification  language  (Ref.  5)  appears  to  be  a 
significant  advance  in  specification  technology  for  practical  systems. 
Despite  its  as  yet  developmental  status,  Anna  is  considered  mature  and 
promising  enough  to  merit  a  limited  trial  application.  This  seems  feasible 
because:  Anna  statements  are  of  the  form  of  actual  Ada  comments,  so  they  are 
ignored  by  an  Ada  compiler;  in  many  cases  they  resemble  Ada  source  code,  so 
they  are  comparatively  readable;  and  above  all  Anna  specifications  need  not 
be  complete,  so  they  can  be  used  to  the  extent  desired  for  any  particular 
program  unit. 

Although  the  processing  of  Anna  statements  normally  involves  associated,  but 
currently  unavailable,  support  software  for  automated  consistency  checks,  the 
addition  of  semantic  definition  to  Ada  specifications  alone  is  expected  to 
yield  more  than  ample  return  for  the  effort  expended  In  particular.  Anna 
holds  promise  of  providing  the  high  quality  specifications  that  are  so  are 
vital  to  fault- tolerant  software. 


Eventually,  it  should  be  possible  to  obtain  the  Anna  support  software,  and  it 
would  doubtlessly  prove  informative  to  evaluate  its  static  consistency 
checking  as  well  as  to  apply  its  dynamic  run-time  checks  during  simulation 
testing.  Exceptions  raised  by  the  run-time  checks  might  well  prove  useful  in 
the  conduct  or  analysis  of  testing.  From  a  fault  avoidance  standpoint,  both 
of  these  types  of  checks  should  improve  software  quality  in  general,  and  from 
a  fault  tolerance  standpoint,  the  dynamic  checks  might  serve  as  acceptance 
tests  in  recoverv  block  mechanizations. 


2.0  SYSTEM  DESIGN 

As  a  framework  and  context  for  the  software  program  unit  specifications,  a 
DFCS  design  was  systematically  developed  that  illustrates  the  precision  and 
accountability  appropriate  for  critical  functions.  Here  only  certain  pitch- 
axis  functions  were  levied  as  requirements  in  order  to  suitably  bound  the 
scope  of  the  software  development  effort.  Accordingly,  the  following  system 
functions  were  included: 

o  Augmented  Fly-by-Wire  (AFBW)  for  a  Negative  Static  Margin  Transport  - 
double  fail-operational  redundancy 

o  Autoland  (Glideslope  and  Flare  Modes)  -  single  fail-operational 

redundancy 

o  Vertical  Navigation  and  Altitude  Hold  (Growth  Provisions  Only)  -  fail- 
passive  . 

Inclusion  of  growth  provisions  was  based  on  a  potential  interfacing  with  a 
navigation  estimation  algorithm  that  Battelle  developed  under  this  same 
contractual  task  to  explore  recovery  block  software  fault  tolerance. 


2.1  System  Description 

The  above  requirements,  especially  the  AFBW  function,  would  typically  result 
in  a  quadruplex  system  architecture  as  depicted  in  Figure  5.  The  redundancy 
levels  and  interconnections  shown  are  representative  of  current  industry 
practice,  based  on  the  safety  and  reliability  requirements  associated  with 
the  above  DFCS  functions.  Four  parallel  MIL-STD- 1553B  multiplex  (MUX)  buses 
are  assumed  for  system  interconnection,  and  the  computer  cross -channel  buses 
are  asynchronous  broadcast  buses  like  ARINC  429. 

Top-level  system  logic  requirements  in  terms  of  MIL-F-9490D  Operational 
States  (Ref.  6)  are  summarized  in  Figure  6.  This  logic,  which  reflects 
system  safety  based  on  the  interaction  between  redundancy  margins  and 
airplane  flying  qualities  status,  is  most  appropriate  for  an  AFBW  function. 
This  system  state  logic,  whose  definition  is  expanded  and  applied  in 
subsequent  sections  on  fault  and  annunciator  logic,  was  ultimately  be 
implemented  in  N-version  software  modules. 

The  system-level  signal  flow  for  a  single  channel,  which  is  typical  of  all 
channels  except  for  the  routing  of  dual  or  triplex  signals,  is  given  in 
Figure  7.  Distribution  of  these  signals  is  clarified  in  Figure  4  or  in  the 
software  interface  definitions.  The  individual  system- level  signals  are 

characterized  in  Figure  8. 

Each  flight  computer  is  postulated  to  be  identical,  with  an  input/output 
processor  (I0P)  for  transferring  and  formatting  external  signals  and  a 
central  processor  unit  (CPU)  for  flight  software  computation.  As  depicted  in 
Figure  9,  the  two  processors  operate  autonomously  and  share  two  sections  of 
memory.  Only  the  I0P  can  write  the  memory  addresses  assigned  to  input 
variables,  and  the  CPU  can  only  read  them.  Similarly,  only  the  CPU  can  write 
the  output  addresses,  and  the  I0P  can  only  read  them.  The  input  data  re¬ 
fresh  rate  is  assumed  to  be  high  enough  such  that  associated  data  skew  or 
phase  lag  are  not  serious  concerns. 
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UNFLYABLE 

OOUBLE.FAIL.OP 
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FAIL. UNSAFE 
DEPLETED 
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Figure  8  -  System-Level  Signal  Summary  (1  of  2) 
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Figure  9  -  Computer  Input/Output  Organization  (Same  for  All  Computers) 
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Figure  10  lists  all  of  Che  DFCS  computer  cross-channel  signals  and  summarizes 
their  salient  characteristics.  Note  that  some  logic  input  signals  require  a 
dedicated  discrete  input  for  a  practical  design,  eg.,  to  provide 
responsiveness  in  the  real-time  coordination  of  resources.  As  far  as  the 
flight  software  is  concerned,  all  input,  output,  or  cross-channel  signals 
could  be  made  available  as  local  data  objects.  However,  for  test 
observability  or  software  voting,  the  level  of  visibility  of  these  objects 
was  raised.  Figure  11  shows  the  interaction  between  the  I0P/CPU  shared 
memory  and  the  input  signal  that  must  be  accomplished  by  the  flight  software. 
The  latter  is  specified  in  Sections  8.0  and  10.0  as  part  of  the  N-version 
test  article. 
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TYPE 


RANGE 


IDENTIf ItK 


Lett  Angie»of -At  tac*  n0.1  float 

Lett  Angle>ot“AttacK  No. 2  • 

Lett  Angle-of “Attack  No,3  " 

Left  Angle-ot-Attack  No. 4  * 

Right  Angle-of “Attack  No.l  * 

Right  Angle-of-Attaek  No. 2  • 

Rlgnt  Angle-ot-Attacn  no. 3  * 

Rlgnt  Angle-of -Attack  No, 4  " 

Channel  Status  No.l  Boolean 

Channel  status  No. 2  * 

Cnannei  Status  No, 3  " 

Channel  Status  No, 4  " 


♦  SO, “10  deg  LEf  T-AUA ( 1 ) 

“  LEET.AOA ( 2 ) 

“  LEfT-AOACJ) 

*  LEET.AOA (  4 ) 

*  R 1GHT.AU A  113 

*  RICHT-AGA12) 

"  HIGHT-AUA13) 

*  KIGHT_A0A(4) 

l  s>  valid  chnl.status.vi 

■  CHNL.STATuS.V2 

*  CHNL.STATUS.V3 

“  CHNL_STaTUS.V4 


NOTE:  All  sensor  inputs  and  their  validity  signals  are  cross-oused  oy  the 
l/o  Processor.  The  logic  signals  are  the  result  ot  software  computation. 


Figure  10  -  Computer  Cross-Channel  Signal  Summary 


3.0  SOFTWARE  DESIGN 


Two  aspects  of  software  design  were  considered:  the  actual  DFCS  flight 
software  for  the  four  computational  channels;  and  the  test  executive  to 
manage  N-version  software  execution  and  assessment  on  a  single  VAX  8650  host 
machine.  This  section  develops  the  DFCS  software  design,  while  the  test 
executive  and  the  overall  demonstration  software  organization  are  presented 
in  Section  14.0. 

For  the  test  article,  note  that  the  lower- level  DFCS  software  in  each  channel 
runs  under  an  autonomous  Ada  task,  DFCS_x_EXEC,  in  Figure  2.  Here  "x" 
denotes  the  DFCS  channel  number.  All  four  of  these  tasks  are  active, 
although  perhaps  blocked,  throughout  testing.  The  DFCS_x_EXEC  tasks  serve  to 
enable  the  non- real - time  testing  of  parallel  channels  in  a  sequential,  yet 
acceptable,  manner  involving  coordinated  task  blocking  at  the  cross-check 
points.  The  basic  point,  however,  is  that  the  same  DFCS  software  can  run  in 
either  parallel  DFCS  processors  or  a  single  test  computer  in  effectively  the 
same  way. 

The  overall  organization  of  each  DFCS  cnannel's  flight  software  is  depicted 
in  Figure  12.  Note  that  the  two  top-level  procedures  are  not  included  in  the 
DFCS  test  article,  but  partial  contents  of  the  top-level  DFCS  packages, 
CHANNEL_RESOURCES  and  SYST£M_RESOURCES ,  are  still  used  in  the  test  set-up. 

The  associated  Ada  source  code  listings  are  given  in  Figure  13,  Parts  a  and  b 


3.1  DFCS  Software  Design 

The  overall  design  of  the  software  was  intended  to  closely  follow  the  prior 
design  of  a  quadruplex  DFCS  that  was  implemented  and  demonstrated  on  the 
RDFCS  (Reconf igurable  DFCS)  Simulator  Facility  at  NASA  Ames  under  the  same 
contract  as  this  task  (Ref.  7).  It  is  expected  that  the  similarities  will 
serve  to  strengthen  the  tutorial  value  of  the  contract  reports  by  viewing 
essentially  the  same  system  from  different  perspectives. 

The  top-level  DFCS  software  design  is  the  same  for  each  channel.  With 
reference  to  Figure  12,  the  main  program  in  each  channel,  RUN_DFCS_MAIN_x .  is 
taken  to  be  an  austere  operating  system  that  establishes  a  given  channel's 
readiness  for  operation  upon  start-up  or  following  a  temporary  disruption. 
Normally  then,  the  second- level  procedure,  RUN_DFCS_EXEC_x ,  directs  ongoing 
system  management  during  normal  operation,  e.g. ,  major  frame  channel 
synchronization.  In  a  complete  flight  software  load  module,  it  also  calls 
Procedure  RUN_FOREGROUND_x ,  which  is  included  in  the  the  N-version  test 
artic le . 

Figure  14  illustrates  the  looping,  multirate  structure  of  RUN_FOREGROL'ND_x . 
which  in  the  test  set-up  is  called  by  Task  DFCS_x_EXEC  of  the  test  harness 
(which  replaces  Procedure  RUN_DFCS_EXEC_x  for  demonstration  purposes).  After 
each  top  -  to -bottom  traversal  of  the  flow  diagram,  control  is  re-assumed  bv 
DFCS_x_EXEC  for  a  simulated  elapsed  time  of  50  millisecond  per  computational 
cycle  as  defined  in  Figure  15).  When  appropriate,  Procedure  RUN_FOREGROUND_x 
is  called  again  and  the  next  one  of  the  four  path  traversals  is  effected. 
Note  in  Figure  14  that  the  N-version  cross-check  points  are  shown  following 
each  of  the  affected  applications  procedures;  at  such  points,  the  four 
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Package  CHANNEL_RESOURCES 


21 


r  a  ~  k  g  <?  f'i'?ft'i-;-Sc!.'r'.iI}CF5  i 5 


1  ects  rations 


croc°c  ’r°  Gnt("h<'u  ; 

"rcc^o  'r*  ; 

cr^c^a'-re  w  j ••  «."Or'L^hnu  j  ; 
"rocf'c.  c>-1'  _?  Q  ^r.'-ri'T  u_<*  ; 

lyre  Lj  °  c  1  c  ”  i  t  li(l 


p«~n_Pf  i.^c.  <  S  I'UF\,r*n  r'irTfc 

"tierc  Tc’  ara'i^ns 


►'^‘vr;_l,  P T ri _ i  ,  yATh  — j,  P^To_4  *  pArt,_H 


er.'l  5 i  ?  t  V ,  „ k. t\- •  u r C ~ -5  ; 


r  e'-oq*  r*o«’:y  SVoTF  io 


o  r  nc°a 

TP 

i>  j  ••' 

_  c  u  ■  “  ■'  j' 

■••-1 

1  s 

C  ^  ~  r  ~  T 

e 

Tt®  j 

T^ 

"  -.r  , 

'  Jm.  it 

l  s 

r  e  r  =  -  d  r 

c 

^  r  ~  c  <»  c. 

■i  r  “ 

^  J  'J 

.E'iia£rrf„ 

'  •-/-  i 

i  s 

c  e  o  o  r  d  * 

e 

T  jLftj 

'  r3 

r- jf 

_>’(j  -  c.  V’  ”.|  ■ 

r 

«.  ** 

1  s 

seDo'i ■ 

c 

“v  s  i  ?  fr  ■•  _  r%  ~  jp;"'  j  ; 


Figure  13b  -  Top-Level  DFCS  Package  Listing 
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channels  muse  synchronize,  exchange  daca,  and  voce  before  executing  to  the 
next  applications  module. 


3.2  DFCS  Applications  Software 

For  years  the  authors  have  used  a  software  design  strategy  that  is  based  on 
control  state  decomposition  (see  Ref.  8),  and  this  sufficed  for  the 
development  of  FAA's  quadruplex  DFCS  at  NASA  Ames.  The  implementation 
language  used  there  (AED) ,  however,  did  not  permit  the  extensive  protection 
of  data  objects  that  Ada  fosters  through  packages  and  strong  typing.  Hence, 
the  the  concern  for  minimization  of  the  data  objects'  namespace  over  the 
total  program  could  not  be  addressed  systematically  until  the  present 
implementation  in  Ada.  The  intent,  of  course,  is  to  alleviate  the 
vulnerability  of  data  objects  to  inadvertant  changes  through  reducing  their 
respective  scopes  in  the  DFCS  software. 

To  accomplish  this,  a  data  flow  decomposition  strategy  (Ref.  9)  has  been 
introduced  at  the  applications  software  level.  Figure  16  depicts  the 
intermediate  step  for  this  design  stage.  System  and  cross -channel  input 
signals  are  introduced  to  a  single  channel  on  the  left,  and  output  signals 
emerge  on  the  right  of  Figure  16.  In  between  new  data  objects  are  identified 
that  are  internal  to  the  DFCS  applications  software,  along  with  their  flow 
relative  to  the  applications  procedures  in  Figure  19.  Finally,  the  three 
intermediate-level  Ada  packages  of  Figure  12  are  shown,  information 
additional  to  that  normally  contained  in  data  flow  diagrams. 

This  data  flow  representation  was  actually  used  to  group  associated  data 
objects  and  procedures  within  these  Ada  packages  and  to  determine  the  levels 
at  which  each  data  object  is  to  be  declared  in  the  Ada-based  design.  The 
lower  the  levels  are  in  general,  the  less  is  the  namespace  over  most  of  the 
program  execution.  This  type  information  is  indicated  to  a  certain  extent 
statically  in  the  call/usage  graph  presented  in  Figure  17.  Definition  of  the 
actual  Ada  package  specification  parts  is  then  initiated  from  information  in 
these  representations. 

Note  that  Figure  17  portrays  appreciable  complexity  and  dispersed 
dependencies  in  the  overall  DFCS/test  program.  This  complexity  is  due  to 
software  fault  tolerance  and  to  the  composition  of  the  test  harness.  Perhaps 
the  biggest  contributing  factor  is  the  non-interference  requirement  imposed 
on  the  test  harness.  Section  lw.O  further  describes  the  mechanization  and 
rationale . 

The  associated  Ada  source  code  listings  for  the  packages  shown  ir.  Figures  lo 
are  presented  in  Figure  18:  (a)  Package  DFCS_LOGIC;  b  Package 

DFCS_RESOURCES ;  (c)  Package  CONTROL_LAWS ;  (d)  Package  N_VERS ION_VOTERS ;  and 

(e)  Package  VOTING_PLANES .  These  package  specifications,  which  capture  much 
of  the  DFCS  applications  software  design  in  non - executab le  Ada  code,  are 
referenced  by  the  Ada  N-version  procedures  pursuant  to  the  namespace 

reduction  strategy. 

All  but  Packages  N_VERSION_VOTER  and  VOTING_PLANES  are  referenced  by 
Procedure  RUN_FOREGROUND_x ,  as  indicated  in  Figures  12  and  17.  The  affected 
applications  procedures  reference  Package  VOTING_PLANES ,  which  effects  cross¬ 
channel  synchronization  and  calls  the  voter  procedure  contained  in  Package 
N_VERSION_VOTER .  The  voting  requirements  are  summmarized  in  Figure  19. 


Figure  16  -  DFCS  Data  Flow  Diagram 


Figure  17  -  Call/Usage  Graph 
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Figure  18b  -  DFCS  Applications  Package  Listing 
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Figure  I8e  -  DFCS  Applications  Package  Listing 
Package  VOTING  PLANES 


IK  PT 

PROCEDURE 

VOTEU  SIGNAL ( S } 

TYPt(S) 

"ATCn 

l 

5£LfcCT-M00fc.Vx 

-IOOt.CNL.Vx 

Record  of  tnameratM 

Exact 

2 

GIVE. STATUS. Vi 

ANNUN.Vx 

Record  of  tnu»er»t«a 

• 

3 

MANACC.At.SeM50kS.Vx 

AL.MC0.VX 

AL.COMP.Vx 

Record  of  f ioets 

Record  of  Boolean  vectors 

TbO 

Exact 

4 

CALC.AUTOLANO.Vx 

AUTOLANU.CML.VX 
AL.PH ASfc.V x 

Float 

Enumerated 

TbD 

Exact 

5 

MANACE.IL.SeNS0R5.Vx 

IL.MED.VX 

IL.COMP.VX 

Record  of  Floats 

Record  ot  boolean  vectors 

TBL 

Exact 

6 

CALC-lNNek.LOOP.VX 

STAfl.SEkVO.CMD.VX 

Float 

TbO 

7 

ASS CSS.S Y STEM. Vx 

FLY-OUAL.Vx 

FbM. STATUS. VX 

Enumerated 

Exact 

8 

G 1 VE. A ARN 1 NG.V I 

NARN.VX 

rLA5H.MARNTNG.Vx 

Record  ot  Enumerated 
Enumerated 

- 

Figure  19  -  N-Version  Voting  Requirements 


Mltn  conthol.LAws  i  use  cqntrol.lams  ; 

■  ltn  DFCS.LUGIC  ;  use  DFCS.LOGIC  i 

■Itn  OFCS.RESOURCES  ;  use  DFCS.RESOUKCts  ; 

separate (SK5TER_HESUUKCES) 
procedure  RUN. FOREGROUND. I  Is 

begin 

SELECT. NODE. VI  ; 
case  PAth.I  is 

men  0  =>  null  ; 

wnen  1  |  }  -> 

ASSESS. L'HANNEL.Vl 

If  PATH. 1  =  1  tnen 

G1VE.5TATUS.V1  ; 

end  If  ; 

MANAGE.AL_SENS0RS.V1  ; 
CALC.AU10LAND.V 1  ; 
anen  2  I  A  => 

ASSESS. SYSTEM. VI  ; 

If  PATH.l  *  4  then 

GIVE.eARNlNU.V 1  : 

end  It  l 

end  case  ; 

MANAGE.IL_SEN50HS.V1  ) 

CALC_1NNER.L00P.V1  ; 

end  run.furegruund.I  ; 


Figure  20  -  Procedure  RUN_FOREGROUND_l  Listing 
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4.0  MULTIRATE  EXECUTIVE  DESCRIPTION 


The  control  structure  of  Procedure  RUN_FOREGROUND_x  was  presented  in  a 
multirate  flow  graph  form  in  Figure  14,  and  the  intent  has  been  to  implement 
it  and  its  called  procedures  such  that  the  applications  software  might  run 
intact  in  either  a  (hypothetical)  target  flight  computer  or  a  host  computer 
test  harness.  The  foreground  executive  procedure  was  implemented  for  each  of 
the  four  DFCS  channels,  and  incorporated  into  the  test  harness  (see  Section 
14.0).  The  Ada  source  code  listing  for  RUN_F0REGR0UND_1  is  given  in  Figure 
20. 

With  the  exception  of  channel/version  number  designations,  the  software  for 
RUN_F0REGR0UND_1  is  the  same  as  for  each  of  the  other  channels.  In  the  names 
of  program  units  such  as  RUN_F0REGR0UND_1 ,  note  that  the  suffix  "l"  by  itself 
denotes  pre-existing  Channel  1  software,  whereas  "VI"  designates  later-to-be- 
developed  Version  1  software.  Of  course,  all  Version  1  software  is  used  in 
Channel  1. 

The  listing  in  Figure  20  is  mainly  the  executable  code  that  calls  the  In¬ 
version  control  function  applications  procedures.  The  location  of  N-version 
cross-check  points  do  not  appear  in  the  listing,  as  Figure  11  might  suggest, 
because  voter  calls  take  place  at  a  lower  level  in  the  program  structure. 
This  is  done  primarily  because  the  same  synchronization  process  is  used  by 
all  voted  procedures.  Also,  it  facilitates  changes  to  procedure  outputs  for 
fault  correction  purposes,  which  is  more  easily  handled  if  the  affected 
procedure  has  not  been  exited.  The  associated  mechanization,  moreover,  seems 
to  afford  some  reductions  of  the  namespace. 

Only  one  version  of  N-version  voting  is  employed  because  multiple  voting 
implementations  would  significantly  and  needlessly  complicate  the 
investigation.  Also,  voting  of  the  foreground  executive  itself  is  avoided  as 
an  unwarranted  addition  of  complexity.  Besides,  the  limited  scope  and  logic- 
oriented  nature  of  DFCS  executives  render  them  amenaDle  to  formal 
verification.  Hence,  the  need  for  software  fault  tolerance  on  this  level  may 
conceivably  be  alleviated.  Such  issues  may  possibly  be  addressed  under  NASA 
Langley  auspices  (see  Ref.  10). 

Timing  intervals  for  the  N-version  code  segments  were  stipulated  in  Figure 
15,  with  a  total  of  50  milliseconds  alloted  for  each  top-down  path  traversal 
in  Figure  14.  Associated  20  Hertz  hardware  timer  interrupts  are  in  general 
assumed  to  be  satisfied  in  all  channels  for  most  N-version  testing  purposes, 
but  code  segment  timeouts  at  cross-check  points  are  to  be  explored  per 
Sec  t ion  14.0. 


5.0  SELECT  MODE  PROCEDURE  SPECIFICATION 


The  operational  mode(s)  of  each  channel  shall  be  determined  based  on 
identical  externally  applied  logic  signals  to  each  channel  and  on  internally 
generated  ones  reflecting  the  availability  conditions  of  the  AFBW  (augmented 
fly-by-wire)  function  and  the  autoland  sensors.  The  internal  logic  shall 
confirm  that  the  selected  mode(s)  is(are)  engagable.  The  resultant  mode 
selection(s)  shall  then  be  furnished  for  activation  of  the  corresponding 
control  functions  and  for  indication  of  mode  engagement  to  the  autopilot 
controller . 


5.1  Autopilot  Modes 


Autopilot  mode  engagement  shall  be  determined  by  the  externally  applied 
logic  signal  M0DE_SEL,  which  is  available  to  all  channels.  The  order  of 
precedence  of  mode  engagement  in  ascending  order  shall  be:  Basic,  Altitude 
Hold,  Vertical  Navigation,  Autoland,  and  Off.  Due  to  external  logic 
interlocks,  when  M0DE_SEL . AUTOPILOT  is  set  at  Autoland,  MOD E_S EL. AUTOLAND 
will  never  be  set  at  off.  The  output  MODE_ENG_Vx . AUTOPILOT  reflects  the 
input  selection  in  all  but  the  Autoland  Mode  which  shall  be  conditionally 
engageable . 


5.2  Autoland  Mode 

The  autoland  selection,  MODE_ENG_Vx .AUTOLAND ,  shall  be  determined  bv  the 
internal  logic  signals,  AL_C0MP_Vx  and  FBW_STATUS_Vx ,  according  to  the 
following  logic  conditions: 

Off  -->  Autoland  Not  Selected  OR  No  Category  Engagable. 

Category  1  -->  Autoland  Selected 

AND  ((Category  1  Selected 

AND  Minimum  of  1  Each  Autoland  Sensors  ) 

OR  (Category  2  or  3  Selected 

AND  [Exactly  1  Sensor  for  at  Least  One  Tvpe  of  Sensor 
AND  At  Least  1  of  Other  Tvpes  of  Sensors 
OR  Operational  State  Less  than  2]1). 

Category  2  -->  Autoland  Selected 

AND  ((Category  2  Selected 
AND  Minimum  of  2  Each  Autoland  Sensors 
AND  Minimum  Operational  State  2( 

OR  (Category  3  Selected 

AND  [at  Least  1  Autoland  Sensor  Fault 

AND  Minimum  of  2  Each  Autoland  Sensors 
AND  Minimum  of  Operational  State  2 
OR  Operational  State  of  2])). 

Autoland  Selected 
AND  Category  3  Selected 

AND  All  Autoland  Sensors 

AND  Operational  State  1. 
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Category  3A  --> 


5.2.1  Autoland  Category  Reversion 


If  failures  occur  during  a  higher  category  autoland,  the  autoland  engagement 
shall  revert  to  the  next  lower  category  whose  engage  logic  is  satisfied. 


5.2.2  Autoland  Select  Warning 

If  Category  2  or  3  Autoland  is  selected,  but  cannot  be  engaged,  this 
situation  shall  be  reflected  in  the  logic  signal  AL_WARN_7x .  If  Category  3 
is  selected,  but  not  engagable.  AL_VARN_Vx  shaLl  be  se~  to  CAT_  3_I.\'0P  If 
Category  2  is  selected,  but  not  engageable,  Al  WARN  7x  stall  be  set  to 
CAT  2  INOP.  In  all  other  cases,  AL  WARN  Vx  shall  be  set  to  OFF. 


5.3  Maximum  Allowable  Computational  Time 

The  maximum  allowable  sub-frame  time  for  this  computation  shall  be  2 
mill iseconds . 


5.4  Inout/Output 


|  INPUTS  | 


AL  COMP  Vx 


AL  SENSOR  STATUS 


type  AL_SENSOR_STATUS  is 
record 

GS_BEAM_VAL 
N_ACCEL_VAL 
RAD_ALT_VAL 
end  record  . 


QUAD_VALIDITY  , 
TRIAD_VALIDITY  ; 
QUAD_VALIDITY  ; 


FBW_STATUS_Vx 

type  PRI_FCS_STATUS  is 

MODE  SEL 


PR I_FCS_STATUS  . 

(0P_STATE_4 ,  OP_STATE_  3 .  0P_STATE_2 
0P_STATE_1 )  ; 

:  AFCS  SELECTION  ; 


type  AFCS_S ELECTION  is 
record 

AUTOPILOT  :  AP_SELECTION 

AUTOLAND  :  AL_CATEGORV 

end  record  , 


type  AP_S ELECTION  is  ( ALT_HOLD ,  AUTOLAND,  BASIC,  VERT_NAV.  OFF' 
type  AL_CATEGORY  is  (CAT_1,  CAT_2 ,  CAT_3A,  OFF  ); 


42 


-v  -v  • 

-  ~  I 


,***■"  J-  .*  /.  .*  .*  v  / 


‘  - 


Ada  Procedure  SELECT  MODE  Vx  ADA 


with  VOTING_PLANES  ;  use  VOTING _ PLANES 
separate ( DFCS_LOGIC ) 
procedure  3ELECT_MODE_Vx  is 

Local  Declarations  (if  any) 

Place  Static  Variables  in  Programmer - De f med  Package's 


--  Using  the  mode  selection/enablement  inputs  as  defined  in  Section 
--  5.4  (as  declared  in  Package  DFCS_LOGICi  determine  the  resultant 
--  output  signals'  mode  engagement  (MODE_ENG_Vx )  and  autoland  warni 
--  (AL_WARN_Vx)  per  the  English  text  specification  requirements. 


begin 


--  Procedure  SELECT  MODE  Vx 


Add  Demonstration  Software  Here 


CHNL_x_XCHK_NUM  1  ; 

XCHK  SYNCH  x  ;  --  Call  for  N-Version  Vote 


end  SELECT  MODE  Vx 


6.0  ASSESS  CHANNEL  PROCEDURE  SPECIFICATION 


Once  a  channel  is  initialized  and  Procedure  RUN_FOREGROUND_x  is  running,  the 
fault  logic  states  of  channel  components  shall  be  monitored  to  ascertain  the 
continued  proper  status  of  the  channel,  independent  of  the  conditions  of  the 
other  channels.  Normally  then,  a  channel  will  be  activated  and  its 
servoactuator  engaged  before  this  procedure  can  be  called.  Once  Procedure 
RUN_FOREGROUND_x  is  operating,  this  procedure  oversees  channel  fault  and 
recovery  events  until  the  maximum  recoveries  below  are  exceeded. 


6.1  Channel  Validity  Logic 

Channel  x's  status,  CHNL_STATUS_Vx ,  shall  be  determined  via  an  examination 
of  the  associated  servo  status,  SERVO_x,  and  the  computer  channel  states, 
CMPTR  x . 


6.1.1  Servo  Validity 


Since  SERV0_x  is  of  Type  Record,  the  various  servo  validities  shall  be 
examined.  All  must  evaluate  True  under  the  limitations  described  below  for 
the  associated  servo  to  be  considered  in  acceptable  condition. 


6.1.2  Computer  Validity 

Similarly,  CMPTR_x  is  a  Record  Type,  so  its  elements  must  all  evaluate  True 
under  the  limitations  prescribed  below  for  acceptability. 


6,2  Logic  State  Change 

The  state  of  CHNL_STATUS_Vx  will  have  been  set  True  prior  to  the  initial 
calling  of  this  procedure  during  any  given  execution.  Having  initially  been 
set  True,  prescribed  time  delays,  or  iteration  counts,  shall  be  observed  in 
declaring  the  channel  validity  False.  Under  certain  conditions,  a  channel 
validity  shall  be  restored  if  a  faulted  item  remains  healed  sufficiently 
long. 

6.2.1  T ime  Delays 


The  following  delays  shall  be  applied  to  the  respective  logic  states  or.  an 
independent  basis.  Specifically,  there  shall  he  no  internal  logic  eourl ing 
of  constituent  validity  states,  so  non-offending  validity  signal s  must  be 
monitored  while  CHNL_STATUS_Vx  is  False  for  other  reasons  CHNL_STATVS  Vx 
shall  be  set  False  if  any  of  the  input  variables  given  below  are  False  for 
the  indicated  number  of  times  in  a  row: 

CPU_CHK_0K 

I0_PR0C_0K 
MUX  BUS  OK 


1  count 
1  count 
3  counts 


ACTUATOR_ON 

LVDT_VALID 
POWER  AVAIL 


3  counts 

4  counts 
1  count 


6.2.2  Channel  Recovery  Delays 


A  channel  shall  recover  and  operate  in  the  foreground  applications  mode  up  to 
a  specified  number  of  times  if  all  appropriate  indications  of  channel 
recovery  and  acceptability  are  satisfied.  Basically,  recovery  indications 
are  particular  durations  of  acceptable  validity  states  following  an 
associated  validity  crip: 


CPU  CHK  OK 


10  PROC  OK 


MUX  BUS  OK 


ACTUATOR  ON 


LVDT  VALID 


POWER  AVAIL 


maximum  of  5  recoveries,  each  following  a 
10-counc  duration  of  validity  after  a  declared 
logic  trip. 

maximum  of  6  recoveries,  each  following  a  50- 
count  duration  of  validity  after  a  declared 
logic  trip. 

maximum  of  2  recoveries,  each  following  a 
50-count  duration  of  validity  after  a  declared 
logic  trip. 

no  limit  or  delav  on  recoveries  in  software 


6.3  Maximum  Allowable  Computation  Time 


The  maximum  allowable  sub- frame  time  for  this  computation  shall,  be  2 
mi lliseconds . 


|  INPUTS  | 


6.4  Input /Output 


CMPTR  x 


:  CMPTR  CHANNEL  STATUS 


type  CMPTR_CHANNEL_STATUS  is 
record 


CPU_CHL_OK 
IO_PROC_OK 
MUX_BUS_OK 
end  record  ; 


SERVO  x 


BOOLEAN  ; 
BOOLEAN  ; 
BOOLEAN  . 


:  SERVO  STATUS  , 


type  SERVO_STATUS  is 
record 

ACTUATOR_ON 
LVDT_VALID 
POWER_ AVAIL 
end  record  ; 


BOOLEAN 

BOOLEAN 

BOOLEAN 


OUTPUTS ■ 


CHNL  STATUS  Vx 


BOOLEAN  ; 


•  -  ^  •  -  * 


Procedure  ASSESS  CHANNEL  Vx 


with  CHANNEL_RESOURCES  ;  use  CHANNEL_RESOURCES  , 
separate (DFCS_LOGIC) 
procedure  ASSESS_CRANNEL_Vx  is 

Local  Declarations  (if  any) 

Place  Static  Variables  in  User-Defined  Package(s) 


--  Using  the  comp"ter  -.hannel  status  and  servo  status  data  as 
--  defined  in  Pack-ge  CHANNEL_RESOURCES ,  determine  the  overall 
--  channel  status,  CHNL_STATUS_Vx ,  per  the  English  text  part  of  the 
--  specification  requirements. 


begin  -  -  Procedure  ASSESS _CHANNEL_Vx 

null ; 


Add  Demonstration  Software  Here 


--  No  N-Version  Vote  Taken  Because  Status  is  Unique  to  each  Channel 
end  ASSESS_CHANNEL  Vx ; 


US 


r.’vyrj  v.^f\;v^rjvjv^<r.\rj 


7.0  GIVE  STATUS  PROCEDURE  SPECIFICATION 


Mode  annunciator  outputs  shall  be  generated  based  on  internal  logic 
computations.  The  outputs  for  pilot  display  shall  include  autopilot 
engage/select  status,  autoland  progress,  and  stability  augmentation 
performance.  Each  computer  channel  will  generate  an  output,  and  the  N- 
version  voter  will  resolve  contradictions. 


7,1  Annunciator  Display  Outputs 

Four  functional  state  outputs  shall  be  generated  as  ANNUN_Vx  per  the  record 
type  ANNUN_STATUS . 


7.1,1  Automatic  Flight  Control  System  Status 

The  autopilot  engage  status  shall  be  derived  from  the  input  MODE_ENG_VX, 
with  the  following  rules  for  the  output  ANNUN_Vx.AFCS_STATUS : 

MODE_ENG_Vx. AUTOPILOT  -  OFF  -->  AFCS_D IS ENGAGED 

MODE_ENG_Vx . AUTOPILOT  -  ALT_H0LD  +  BASIC  +  VERT_NAV 

-->  AUTOPILOT_ENCAGED 

MODE  ENG  Vx. AUTOPILOT  -  AUTOLAND  -->  AUTOLAND  ENGAGED 


7.1.2  Autopilot  Mode  Engagement 

The  autopilot  mode,  ANNUN_Vx . AUTOPILOT_MODE ,  shall  be  set  equal  to  the 
selected  autopilot  mode,  MODE_ENG_Vx . AUTOPILOT ,  since  they  are  both  of  Tvpe 
AP_S ELECTION. 

7.1.3  Autoland  Progress 

If  MODE_ENG_Vx. AUTOPILOT  -  AUTOLAND.  the  autoland  progress  display 
ANNUN_Vx . AL_PROG_DISP ,  a  1x5  Boolean  vector.  shall  reflect  the  input  state 
and  input  sequence  furnished  by  AL_PHASE_Vx.  Progress  shall  be  indicated  bv 
setting  corresponding  output  vector  elements  to  True  Except  for 

AUT0LAND_IN0P ,  this  Boolean  vector  has  a  one-to-one  correspondence  with  the 
values  of  the  enumerated  type  AL_PROGRESS  :  AUTOLAND_ARMED . 

GLIDES  LOPE_TRACK ,  DECISION_ALTITUDE’,  ALERT_ALTITUDE ,  FLARE.  Normal  autoland 
progress  is  noted  by  stepping  through  these  phases  in  the  above  order  with 
the  following  externally  controlled  exceptions: 

o  Category  1  progress  proceeds  only  through  DECISION_ALTITUDE 

o  Category  2  skips  ALERT_ALTITUDE 

o  Category  3A  skips  DECISION  ALTITUDE. 


The  output  ANNUN_Vx . AL_PROG_DISP  should  reflect  the  progression  observed  by 
indicating  the  cumulative  phases.  Thus,  once  AL_PHASE_Vx  is  set  to 
AUTOLAND_ARMED ,  it  and  the  succeeding  phases  shall  all  be  recorded  in 
ANNUN_Vx.AL_PROG_DISP,  until  MODE_ENG_Vx . AUTOPILOT  is  no  longer  in  AUTOLAND. 
If  AL_PHASE_Vx  -  AUTOLAND_INOP -or  if  MODE_ENG_Vx  AUTOPILOT  -  Not  AUTOLAND, 
all  components  of  ANNUN_Vx . AL_PROG_DISP  shall  be  set  to  False 


7,1.4  Augmented  Flying  Qualities 

The  augmented  flying  qualities,  as  defined  by  FLY  Ql’AL  Vx.  shall  be 
displayed  as  output  by  ANNUN_Vx . FLY_QLTY  exactly  as  furnished  at  the  program 
unit  input. 


7,2  Update  Conditions 

Annunciator  display  updates  shall  be  immediate,  with  a  logic  calculation 
iterations  at  a  20  Hz  rate. 


7.3  Maximum  Allowable  Time 


The  maximum  allowable  sub-frame  for  this  computation  shall  be  2 
milliseconds . 


7.4  Input/Output 


|  INPUTS) 


AL_PHASE_Vx  :  AL_PR0GRESS  ; 

type  AL_PR0GRESS  is  (AUTOLAND_ARMED ,  GLIDESLOPE_TRACK . 

DECISION_ALTITUDE ,  ALERT_ALTITUDE ,  FLARE .  AUT0LAND_IN0P 

FLY_QUAL_Vx  :  FLYING_QUALITIES  ; 

type  FLYING_QUALITIES  is  (UNFLYABLE,  MARGINAL.  DEGRADED,  NORMAL 

MODE_ENG_Vx  :  AFCS_SELECTION  ; 

type  AFCS_SELECTION  is 

record 

AUTOPILOT  '  AP_SELECTION  ; 

AUTOLAND  :  AL_CATEGORY  ; 

end  record  ; 

type  AP_SELECTI0N  is  (ALT_HOLD,  AUTOLAND,  BASIC,  VERT _NAV ,  OFF)  ; 
type  AL_CATEGORY  is  (CAT_1,  CAT_2 ,  CAT_3A,  OFF  ), 


|  OUTPUTS  | 


ANNUN_Vx  :  ANNUN_STATUS  ; 

type  ANNUN_STATUS  is 
record 

AFCS_STATUS 
AL_PROG_DISP 
AUTOPILOT_MODE 
FLY_QLTY 
end  record  ; 

type  ENGACE_STATUS  is  (AFCS_D IS ENGAGED ,  AUTOPLIOT_ENGAGED 

AUTOLAND_ENGAGED)  ; 

type  CUM_AL_PROGRESS  is  array  (1..5)  of  BOOLEAN  ; 

type  AP_SELECTION  is  (ALT_HOLD,  AUTO  LAND ,  BASIC,  VERT_NAV ,  OFF' 

type  FLYING  QUALITIES  is  (UNFLYABLE,  MARGINAL,  DEGRADED.  NORMAL) 


ENGAGE_STATUS  ; 
CL'M_AL_PROGRESS 
AP_SELECTION  ; 
FLYINC_QUALITIES 


Ada  Procedure  GIVE  STATUS  Vx 


with  VOTING_PLANES  ;  use  VOT I NG_ PLANES  ; 
separate (DFCS_LOGIC) 
procedure  GIVE_STATUS_Vx  is 

Local  Declarations  (if  any) 

Declare  Static  Variables  in  User  Defined  Package  C  s 's 


--  Using  the  inputs  AL_PHASE_Vx,  FLY_QUAL_Vx .  and  MODE_ENG_Vx, 
--  compute  the  appropriate  outputs  to  the  Annunciator  Displavs 
--  ANNUN_Vx  per  the  logic  requirements  in  the  English  language 
--  specification. 


begin 


Procedure  GIVE  STATUS  Vx 


--  Add  Demonstration  Software  Here 


CHNL_x_XCHK_NUM  : -  2 
XCHK_S YN  CH_x  ; 


end  GIVE  STATUS  Vx 


8.0  MANAGE  AL  SENSOR  PROCEDURE  SPECIFICATION 


Whenever  the  autopilot  is  engaged,  the  various  sensors  needed  for  automatic 
approach  and  landing  shall  be  voted  and  compared  to  ensure  the  integrity  of 
the  signals  used  for  autoland.  Direct  and  cross -channel  inputs  shall  be 
processed,  and  the  results  shall  be  placed  in  a  record  data  structure.  Logic 
states  shall  be  maintained  regarding  both  the  internal  and  external  status  of 
the  various  sensor  signals. 


8.1  Sensor  Signal  Voting 

Three  separate  autoland  sensor  signal  votes  shall  be  made  on  the  input 
vectors  each  cycle:  Glideslope  Beam  Deviation  (CS_BEAM_D£V) ,  Normal  or 
Vertical  Acceleration  (NORM_ACCEL) ,  and  Radio  Altitude  (RAD_ALTITUDE) .  In 
each  case  a  median  output  signal  shall  be  generated  and  placed  in  a  record, 
AL_MED_Vx.  Where  an  even  number  of  inputs  is  applied,  the  median  shall  be 
taken  as  the  lesser  of  the  two  middle  signal  values. 

8.1.1  Signal  Ranges 

The  range  of  the  respective  input  signals  shall  be  defined  in  the  derived 
type  definitions  in  Package  DFCS_RESOURCES ,  Figure  18c.  Note  that  type 
conversions  to  Float  may  be  necessary  at  some  point. 

8.1.2  Input  Signal  Validities 

If  the  input  validity  signal  associated  with  any  input  sensor  signal,  as 
reflected  in  the  record  AL_FLAGS ,  is  False  5  consecutive  iterations,  the 
sensor  signal  shall  be  removed  as  an  input  to  the  corresponding  voter.  The 
associated  signal  comparator  in  AL_C0MP_Vx  shall  then  be  set  to  False 
(tripped  state)  until  5  consecutive  True  values  of  the  associated  input 
validity  flag  signal  are  observed.  The  fault  logic  trip  due  to  external 
signals  flags  shall  be  permitted  to  heal  as  many  times  as  this  logic  is 
satisfied. 

8.1.3  Signal  Comparators 

Each  of  the  non-faulted  input  sensor  signals  shall  be  applied  to  a 
corresponding  voter  and  shall  be  compared  everv  iteration  with  the  current 
median  signal  output  of  the  voter.  When  the  associated  time  and  amplitude 
thresholds  are  simultaneously  exceeded,  the  affected  input  signal  shall  be 
declared  faulted  in  AL_C0MP_Vx,  and  the  signal  shall  be  discontinued  as  an 
input  to  the  voter.  The  associated  fault  logic  shall  latch,  for  no  healing 
of  comparison  faulted  sensor  signals  shall  occur. 

8.1.4  Amplitude  Thresholds 

The  following  absolute  values  of  signal  comparator  differences  (each  voter 
input  compared  with  the  corresponding  voter  output)  shall  delineate  out-of¬ 
tolerance  input  signals  for  the  respective  types  of  sensors: 


Glideslope  Beam  Deviation 

>- 

0 

05 

degrees 

Normal  Acceleration 

>- 

0 

025 

g- 

Radio  Altitude 

>  = 

2%  of 

current  median 

value  of  altitude 


8.1.5  Time  Thresholds 


The  following  number  of  successive  oi 
shall  constitute  the  time  thresholds 
Note  that  the  comparisons,  and  hence 
call  of  this  procedure. 

Glideslope  Beam  Deviation 
Normal  Acceleration 
Radio  Altitude 


-  of  - 

tolerance 

input  sensor  comparisons 

for 

dec lar ing 

a  faulty  input  signal. 

each 

i  count. 

is  onlv  made  every  other 

>- 

5  counts 

>- 

4  counts 

>- 

4  counts 

8,2  Output  Signals 

The  median  output  signals  and  the  comparator  state  logic  shall  be  available 
as  data  objects  exported  by  Packages  DFCS_R£SOURCES  and  DFCS  LOGIC 
respectively . 

8.2.1  Median  Output  Signals 

The  median  output  signals,  AL_MED_Vx ,  shall  be  a  record  of  Tvpe 
AL_SENSOR_SET . 

8.2.2  Comparator  State  Output  Signals 

The  comparator  state  output  signals,  AL_COMP_Vx ,  shall  be  a  record  of  Tvpe 
AL_SENSOR_STATUS .  AL_COMP_Vx  shall  reflect  the  total  effect  of  input  sensor 
validity  flags  and  the  internal  sensor  comparator  validities,  i  e  the  flat 
input  for  any  sensor  shall  be  OR-ed  with  the  associated  comparator  validitv 
to  obtain  the  corresponding  AL_COMP_Vx  component  value  The  resultant  states 
shall  determine  which  input  sensor  signals  are  applied  to  the  voters 


8.3  Program  Structure  Requirements 

From  a  static  standpoint,  Procedure  MANAGE_AL_SENSCRS  *'x  is  incorporated 
into  the  program  structure  as  shown  in  the  call  usage  graph  in,  Ficure  l-> 
From  a  dynamic  standpoint,  the  multirate  executive  control  flow  in  F.cire  11 
depicts  the  invocation  of  MANAGE_AL_SENSORS_'.'x  . 

8.3.1  Iteration  Rate 


As  shown  in  Figure  14,  the  iteration  rate  for  the  autoland  sensor  processing 
is  10  Hz. 


8.3.2  Maximum  Allowable  Computation  Time 

As  indicated  in  Figure  15,  the  maximum  allowable 
MANAGE  AL  SENSORS  Vx  is  5  milliseconds 


8,4  Input/Output 


|  INPUTS  | 


GS_BEAM_DEV  :  GS_DEV_QUAD  ; 

type  GS_DEV_QUAD  is  array  (1..4)  of  BEAM_DEV_S IGNAL 

type  BEAM_DEV_S IGNAL  is  new  FLOAT  range  -25  .25  , 

NORM_ACCEL  :  N_ACCEL_TRIAD  ; 

type  N_ACCEL_TRIAD  is  array  (1..3)  of  ACCEL_S IGNAL  ; 
type  ACCEL_SIGNAL  is  new  FLOAT  range  -1.0,. 3.0  ; 

RAD_ALTITUDE  :  RAD_ALT_QUAD  ; 

type  RAD_ALT_QUAD  is  array  (1..4)  of  RAD_ALT_S IGNAL  ; 
type  RAD_ALT_S IGNAL  is  new  FLOAT  range  -  20 . 0 .  . 2500 . 0  ; 

AL_FLACS  :  AL_SENSOR_STATUS  ; 

type  AL_S ENSOR_STATU S  is 
record 

GS_BEAM_VAL  :  QUAD_VALID  ; 

N_ACCEL_VAL  :  TRIAD_VALID  ; 

RAD_ALT_VAL  :  QUAD_VALID  , 

end  record  ; 


|  OUTPUTS  | 


AL_C0MP_Vx 

AL_MED_Vx 

type  AL_SENSOR_SET 
record 

CS_DEV 
N_ACCEL 
RAD_ALT 
end  record  : 


AL_SENSOR_STATUS  ; 
AL_SENSOR_SET  ; 

BEAM_DEV_S IGNAL  ; 
ACCEL_S IGNAL  ; 

RAD  ALT  SIGNAL  ; 


Ada  Procedure  MANAGE  aL  SENSORS  7x 


with  DFCS_LOGIC  ;  use  DFCS_LOGIC  , 
with  VOTING_PLANES  ;  use  VOT I NG_ PLANES 
separate(DFCS_RESOURCES ) 
procedure  MANAG E_AL_ SENSORS _Vx  is 

Local  Declarations  (if  any) 

Place  Static  Variables  in  User  Defined  Packagers 


--  Using  the  sets  of  autoland  sensor  inputs  (GS_BEAM_DE7 , 

--  NORM_ACCEL,  RAD_ALTITUDE) ,  compute  the  respective  median  value 
--  outputs  for  AL_MED_Vx,  per  the  English  text  specification 
-  -  requirements . 

--Do  not  vote  an  input  signal  if  its  associated  validity  flag, 

--  AL_FLAGS(y),  is  False  for  a  prescribed  period  Then  the  indicated 
--  fault  should  be  reflected  in  the  corresponding  output  comparator 
--  logic,  AL_COMP_Vx(y) . 

--  Compare  each  signal  input  with  the  associated  median  value,  and 
--  if  out  of  specification  tolerance,  note  a  comparator  trip  in 
--  AL_COMP_Vx(y) . 


begin  --  Procedure  MANAGE_AL_SENSORS_Vx 


Add  Demonstration  Software  Here 


CHNL_x_XCHK_NUM  3  ; 

XCHK  SYNCH  x  ;  -  Call  for  N-V'ersion  Vote 


end  MANAGE  AL  SENSORS  Vx  ; 


9.0  CALC  AUTOLAND  PROCEDURE  SPECIFICATION 


Glideslope  tracking  and  Landing  flare  functions  shall  be  provided  as  an 
orderly  sequence  of  pitch  axis  sub-modes  for  automatic  approach  and  landing 
under  Category  I,  II,  and  Ilia  weather  conditions.  Appropriate  fault 
survivability  capability  will  be  provided  based  on  fault  logic  external  to 
this  procedure.  Depending  on  mode  selection  and  component  availability, 
autoland  status  annunciation  outputs  shall  be  generated  for  external  display. 

9.1  Control  Laws 

The  glideslope  and  flare  control  laws  shall  be  in  accord  with  the  analytical 
block  diagram  presented  in  Figure  21.  Neither  fixed  point  nor  extended 
precision  floating  point  arithmetic  shall  be  used 

9.1.1  Signal  Shapine 

Digital  filtering  (as  contrasted  with  numerical  integration,  for  example) 
shall  be  used  for  the  transfer  functions.  The  sampling  interval  T  shall  be 
in  accord  with  the  iteration  rate  in  paragraph  9.4.1.  The  Tustin  transform 
may  be  used  on  the  complex  frequency  operator.  s.  to  obtain  z,  the  complex 
delay  operator  as  appears  in  digital  filter  equations: 

s  -  2  (2-1) 

T  (z+1) 

Since  all  of  the  filters  are  first-order,  only  the  one  previous  input  and 
output  difference  equation  values  must  be  saved.  These  saved  values  must  be 
initialized,  moreover,  before  mode  engagement  to  preclude  spurious  transient 
steering  commands.  Specifically,  high-pass  filters  (those  with  an  s-operator 


in  the  numerator)  must  have  their  past  input  values  set  to  input  values 
present  at  engagement  time,  and  their  past  output  values  set  to  zero.  Low- 
pass  filters  (those  with  only  a  constant  in  the  numerator)  must  have  their 
outputs  and  saved  values  set  to  zero  prior  to  engagement.  The  effect  in  both 
cases  is  to  null  filter  outputs  for  the  first  computational  cycle  following 
mode  engagement. 

9.1.2  De - sens i t iza t ion  Schedule 

The  glideslope  beam  deviation  signal  shall  be  de - sens i t ized , or  down-gained, 
as  a  function  of  decreasing  radio  altitude  as  shown  in  Figure  21  to  offset 
the  effects  of  beam  convergence 

9.1.3  Glideslope  Fader 

Since  some  residual  glideslope  error  signal  may  be  present  at  flare  engage, 
an  exponential  bleed-off  signal  fader  shall  be  activated  for  Category  II  or 
Ilia  autoland  at  flare  engage,  simultaneously  with  the  switching  in  of  the 
flare  command  signal  per  Figure  21.  Category  I  approaches  shall  terminate  at 
the  Decision  Altitude,  and  shall  use  this  same  fader  to  bleed  off  anv 
residual  command  at  this  point. 
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9.1.4  Flare  Sink  Rate  Command 

For  Category  II  or  Ilia  autoland,  an  exponential  flare  path  shall  be 
generated  upon  descent  to  60  feet  of  radio  altitude  in  accordance  with  the 
altitude  scheduling  of  the  sink  rate  command  as  shown  in  Figure  21. 

9.1.5  Altitude  Rate  Signal 

An  altitude  rate  signal  shall  be  synthesized  from  normal  acceleration  and 
radio  altitude  as  blended  through  complementary  filtering  as  shown  in  Figure 
21.  This  signal  shall  be  summed  with  sink  rate  command  to  obtain  sink  rate 
error  during  both  glideslope  and  flare  modes. 


9.1.6  Command  Rate  Limiting 

Excursions  of  the  sink  rate  error  signal  shall  be  limited  by  a  command  rate 
limiter  per  Figure  21  to  preclude  spurious  or  extreme  flight  path 
corrections . 


9.1.7  Command  Loop  Closure 

The  autoland  loop  closure  shall  be  effect  through  the  summation  of  the  sink 
rate  command  with  pitch  rate  as  shown  in  Figure  21.  Pitch  rate  shall  be 
obtained  from  IL  MED  Vx.P  RATE. 


9,2  Mode  Engagement  Logic 

Autoland  mode  engagement  shall  be  effected  via  the  logical  signal 
MODE_ENG_Vx . AUTOPILOT  -  AUTOLAND,  which  reflects  both  pilot  mode  selections 
and  component  availability.  The  mode  selection  logic  shall  be  used  along 
with  the  radio  altitude  signal  to  activate  control  law  sub-modes  and  to 
perform  the  autoland  progress  display  logic  computations. 

9.2.1  Glideslope  Mode  Engagement 

The  glideslope  mode  shall  be  active  in  beam  tracking  mode  for  Categories  II 
and  Ilia  autoland  any  time  the  radio  altitude  is  above  60  feet.  The  radio 
altimeter  level  detector  shall  be  included  in  Procedure  CALC  AUTOLAND  Vx . 


9.2.2  Flare  Mode  Engagement 

The  flare  mode  shall  be  engaged  for  either  Category  II  or  Ilia  autoland  when 
the  radio  altitude  is  below  60  feet. 


9.2.3  Autoland  Progress  Display 

The  following  logic  conditions  shall  be  observed  in  determining  output  logic 
states,  AL_PHASE_Vx,  for  annunciation.  Since  it  is  an  enumeration  tvpe  data 
object,  the  assignments  below  are  made  upon  satisfaction,  and  remain  or.iv 
until  another  condition  is  fulfilled,  or  until  the  Autoland  Mode  is  reset. 

AUTOLAND_ARMED  -->  Category  II  or  Ilia  Engaged 

GLIDESLOPE_TRACK  -->  Glideslope  Mode  Engaged  i  presumed 

DECISION_ALTITUDE  -->  Categorv  I  Engaged  ' h  <-  200  ft  or 

Category  II  Engaged  ■  <h  <=  150  ft. 

ALERT_ALTITUDE  -->  Category  Ilia  *  (h  <-  100  ft.  ) 

FLARE  -->  (Category  II  or  Category  Ilia)  *  (h  <-  60  ft  > 

AUT0LAND_IN0P  -->  Category  II  and  Ilia  Engage  Logic  Lost  During 
Approach  or  Landing  or  when  Autoland 
De - Se lected 


9.3  Signal  Interfaces 

All  sensor  input  signals  will  have  been  voted  prior  to  receipt  bv  Procedure 
CALC_AUT0LAND_Vx  to  eliminate  discrepant  inputs  due  to  hardware  faults 


9.3.1  Signal  Inputs 

All  sensor  inputs  are  derived  types  with  constraints  as  follows.  Tvpe 
conversions  to  Float  are  therefore  needed.  Unit  conversion  from  g's  to  feet 
per  second  squared  for  normal  acceleration  are  also  needed. 

o  Glideslope  Beam  Deviation:  +/-  2.5  degrees 

o  Normal  Acceleration.  1.0/+3.0  g’s 

o  Radio  Altimeter.  •  20/+2500  feet 

o  Pitch  Rate:  +/-  25  deg/sec 


9,3.2  Logic  Inputs 

The  logic  inputs  M0DE_ENG_Vx  is  a  record  of  enumeration  tvpes 


9.3.3  Pitch  Command  Output 

The  output  steering  command.  AUTOLAND  CMD_Vx,  is  a  derived  tvpe  with  a  i  ange 
constraint  of  6.0/+3  0  degrees  per  second  A  tvpe  conversion  from  Float  is 
therefore  needed  for  this  output 
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9.3.4  Logic  Output 


The  logic  output,  AL_PHASE_Vx,  is  an  enumeration  tvpe . 


9.4  Program  Structure 

From  a  static  standpoint,  CALC_AUTOLAN'D_Vx  is  incorporated  into  the  program 
structure  as  shown  in  the  call/usage  graph  in  Figure  17;  from  a  dynamic 
standpoint,  the  multirate  executive  structure  in  Figure  14  depicts 
CALC_AUTOLAND_Vx' s  invocation. 

9.4.1  Iteration  Rate 

As  evident  in  Figure  14,  the  iteration  rate  for  the  autoland  calculations  is 
10  Hz. 


9,4,2  Maximum  Allowable  Computation  Time 

As  indicated  in  Figure  15,  the  maximum  allowable  computation  time  for 
CALC_AUTOLAND_Vx  is  4  milliseconds 

9.5  Input /Output 


|  INPUTS  | 


MODE_ENG_Vx  ;  AFCS_SELECTION  ; 

type  AFCS_SELECTION  is 
record 

AUTOPILOT  :  AP_SELECTION  ; 

AUTOLAND  ;  AL_CATEGORY  ; 

end  record  ; 


type  AP_SELECTION  is  (ALT_HOLD ,  AUTOLAND,  BASIC,  VERT_NAV ,  OFF) 
type  AL_CATEGORY  is  (CAT_1,  CAT^_2 ,  CAT_3A.  OFF)  ; 


AL  MED  Vx 


AL_SENSOR_SET  ; 


type  AL_SENSOR_SET  is 
record 

GS_DEV  :  BEAM_DEV_S IGNAL  ; 

N_ACCEL  :  ACCEL_S IGNAL  ; 

RAD_ALT  ;  RAD_ALT_S IGNAL  ; 

end  record  ; 


type  BEAM_DEV_S IGNAL  is  new  FLOAT  range  -2. 5.. 2. 5  ; 

type  ACCEL_SIGNAL  is  new  FLOAT  range  -1.0.  3.0  ; 

type  RAD_ALTSIGNAL  is  new  FLOAT  range  -  20 . 0 .  . 2500 . 0 
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IL_MED_Vx  :  IL_SENSOR_SET  ; 

Cype  IL_SENSOR_SET  is 
record 

o 

o 

P_RATE  :  ANG_RATE_SIGiNAL  ;  (only 

o 

end  record  ; 


|  OUTPUTS  | 


AUTOLAND_CMD_Vx  :  PITCH_COMMAND  ; 

type  PITCHJCOMMAND  is  new  FLOAT  -5.0..10.0  ; 

AL_PHASE_Vx  :  AL_PROGRESS  ; 

type  AL_PROGRESS  is  (AUTOLAND_ARMED , 

DECISION  ALTITUDE,  ALERT  ALTITUDE,  FLARE,  AUTOLAND_INOP) 


componenc  needed; 


GLIDESLOPE  TRACK 


Ada  Procedure  CALC  AUTOLAND  Vx 


with  DFCS_LOGIC  ;  use  DFCS_LOCIC  ; 
with  DFCS_RESOURCES  ;  use  DFCS_RESOURCES  ; 
with  VOTING_PLANES  ;  use  VOTING_PLANES  ; 
separate ( CONTROL_LAWS ) 
procedure  CALC_AUTOLAND_Vx  is 

Local  Declarations  (if  any) 

Place  Static  Variables  in  User-Defined  Package! s) 


--  Conditional  upon  proper  mode  logic  input,  MODE_ENG_Yx ,  calculate 
--  the  pitch  axis  autoland  command,  AUTOLAND_COMMAND_Yx ,  using  the 
--  sensor  inputs,  AL_MED_Vx  and  IL_MED_Vx . P_RATE 

--  autoland  is  engaged,  compute  the  progress  display  outputs, 

--  AL  PHASE  Vx ,  as  well. 


begin 


--  Add  Demonstration  Software  Here 


CHNL_x_XCHK_NUM  : -  4 
XCHK_SYNCH_x  ; 

end  CALC  AUTOLAND  Vx 
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10.0  MANAGE_IL_SENSORS  PROCEDURE  SPECIFICATION 


During  all  foreground  executive  program  execution,  the  inner  loop  sensor  and 
command  input  signals  shall  be  voted  and  compared  to  ensure  the  integrity  of 
the  signals  used  for  DFCS  functions.  Direct  and  cross-  channel  inputs  shall 
be  processed,  and  the  results  placed  in  appropriate  record  data  structures. 
Logic  states  shall  be  maintained  regarding  the  status  of  the  various  input 
signal  sources . 

10 . 1  Sensor  Signal  Voting 


Five  separate  inner  loop  sensor  signal  votes  shall  be  made  on  the  input 
vectors:  Pilot's  Stick  Command  ( P_STICK_CMD ) ,  Copilot's  Stick  Command 
(CP_STICK_CMD) ,  Average  Angle-of-Attack  (to  be  named),  True  Airspeed 
(TRUE_AIRSPEED) ,  and  Pitch  Rate  ( P_RATE_GYRO) .  In  each  case  a  median  output 
signal  shall  be  generated  and  placed  in  a  record,  IL_MED_Vx.  Where  there  are 
an  even  number  of  inputs  applied,  the  median  shall  be  taken  as  the  lesser  of 
the  two  middle  value  signals. 


Signal  Ranees 


The  range  of  the  respective  input  signals  are  defined  in  Section  10  4.  Since 
these  signals  are  of  derived  types.  type  conversion  to  Float  type  may  be 
necessary  for  calculation  purposes. 

10.1.2  Input  Signal  Validities 

If  the  input  validity  flag  signals  furnished  by  the  repsective  sensors,  per 
IL_FLAGS,  is  False  5  consecutive  iterations,  the  sensor  signal  shall  be 
removed  as  an  input  to  the  corresponding  voter.  The  associated  signal 
comparator  output,  IL_C0MP_Vx,  shall  then  be  set  to  False  (tripped  state > . 
Following  a  particular  logic  trip,  5  consecutive  True  inputs  per  IL_FLAC-S 
shall  reset  the  corresponding  IL_C0MP_Vx  state 

10.1.3  Angle-of-Attack  Inputs 

Each  corresponding  left  and  right  angle-of - attack  signal  pair  shall  be 
averaged  prior  to  being  voted,  as  illustrated  in  Figure  7, 

10.1.4  Signal  Comparators 

Each  of  the  input  signals  applied  to  a  particular  voter  shall  be  compared 
each  iteration  with  the  current  median  signal  output  When  the  associated 
time  and  amplitude  thresholds  are  s imul taneous lv  exceeded,  the  affected  input 
signal  shall  be  declared  faulted  in  IL_C0MP_Vx,  and  it  shall  be  permanently 
discontinued  as  an  input  to  the  voter. 
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The  following  absolute  values  of  signal  comparator  differences  (between  the 
median  value  and  that  of  each  voter  input)  shall  delineate  out  -  of  -  to lerance 
input  signals  for  the  respective  types  of  signals: 


Pilot's/Copilot's  Stick  Command 

>- 

0  , 

2  degrees 

Angle -of -Attack 

>- 

1 

25  degrees 

True  Airspeed 

>- 

10 

knots 

Pitch  Rate 

>- 

1 . 

0  degrees/second 

10.1.6  Time  Thresholds 


The  following  number  of  consecutive  out-of -tolerance  amplitude  comparisons 
shall  constitute  the  time  thresholds  for  declaring  a  faulty  input  signal: 


Pilot's/Copilot's  Stick  Command 
Angle-of -Attack  &  Pitch  Rate 
True  Airspeed 


>—  6  counts 
>-  8  counts 
>-  16  counts 


10.2  Output  Signals 

The  median  output  signals  and  the  sensor  status  logic  shall  be  available  as 
data  objects  exported  by  Packages  DFCS_RESOURCES  and  DFCS_L0GIC. 
respective ly . 


10.2.1  Median  Output  Signals 

The  median  output  signals,  IL_MED_Vx.  shall  be  a  record  of  Tvpe 
IL  SENSOR  SET 


10.2.2  Sensor  Status  Output  Signals 

The  sensor  status  signals.  IL_C0MP_Vx.  shall  be  a  record  of  Tvpe 
IL  SENSOR  STATUS 


10.3  Program  Structure  Requirements 

From  a  static  standpoint,  Procedure  MANAGE_I  L_StNS0RS_V\  is  :  r.c  '  rpnruted 
into  the  program  structure  as  shown  in  the  call  usage  graph  :r.  Figure  t ' 
From  a  dynamic  standpoint,  the  multirate  executive  structure  in  Figure  la 
depicts  the  invocation  of  MANAGE_IL_SENSORS_Vx 


10.3.1  Iteration  Rate 


As  shown  in  Figure  14,  the  iteration  rate  for  the  inner  loop  sensor 
processing  shall  be  20  Hz. 
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10.3.2  Maximum  Allowable  Computation  Ti 

As  indicated  in  Figure  15, 
MANAGE  IL  SENSORS  Vx  is  5  milliseconds. 


10.4  Input/Output 


|  INPUTS  | 


CP  STICK_CMD 

LEFT_A0A 

P_RATE_GYRO 

P_STICK_CMD 

RIGHT_A0A 

TRUE  AIRSPEED 


STICK_CMD_QUAD  ; 
A0A_QUAD  ; 
RATE_GYRO_TRIAD  ; 
STICK_CMD_QUAD  ; 
AOA_QUAD  ; 
TAS_PAIR  ; 


IL  FLAGS 


IL  SENSOR  STATUS 


type  IL_SENSOR_STATUS  is 
record 

AV  G_AO A_VA  L 
CP_STK_VAL 
LF_AOA_VAL 
P_STK_VAL 
P_RATE_VAL 
RT_AOA_VAL 
TAS_VAL 
end  record  ; 


QUAD_VALI  D  ITT’  ; 
QUAD_VALIDITY  ; 
QUAD_VALIDITV  , 
QUAD_VALIDITY  , 
TRIAD_VALIDITY  ; 
QUAD_VALIDITY  ; 
PAIR  VALIDITY  ; 


|  OUTPUTS  | 


IL  MED  Vx 


IL  SENSOR  SET 


type  IL_SENSOR_SET  is 
record 

AOA_DISPL 
CP_STICK 
P_RATE 
P_STICK 
TR_AIRSPEED 
end  record  ; 


A0A_S IGNAL  , 
STICK_CMD  : 
ANG_RATE_S IGNAL 
STICK_CMD  ; 

TAS  SIGNAL  ; 


type 

ANG_ 

RATE  SIGNAL 

is 

new 

type 

A0A_ 

'signal 

is 

new 

type 

STICK_CMD 

is 

new 

type 

TAS_ 

SIGNAL 

is 

new 

IL  COMP  Vx 


FLOAT  range  -25.0. .25.0 
FLOAT  range  - 10. 0.. 50.0 
FLOAT  range  - 1 . 5 ,  . 0 . 5  ; 
FLOAT  range  100 . 0 . . 600 . 0 

:  IL  SENSOR  STATUS  ; 


-  -  deg,  sec 

-  -  degrees 

-  -  degrees 

-  -  knots 


Ada  Procedure  MANAGE  IL  SENSORS  Vx 


with  DECS_LOCIC  ,  use  DFCS_LOCIC  ; 

with  VOTING_PLANES  ;  use  VOTING^ PLANES  ; 
separate ( DFCS_RESOURCES ) 
procedure  MANAGE_IL_SENSORS_Vx  is 

Local  Declarations  (if  any) 

Place  Static  Variables  in  User-Defined  Packageis) 


--  Using  the  Voter /Comparator  Inputs  (CP_STICK_CMD .  LEFT_AOA, 

--  P_RATE_GVRO .  P_STICK_CMD ,  RIGHT_AOA ,  TRUE_AIRS PEED )  compute 
--  the  median  value  outputs,  IL_MED_Vx,  per  the  English  test 
--  specification  requirements. 

--  Do  not  vote  an  input  signal  if  its  associated  validitv  flag 
--  IL_FLAGS(y),  is  False  Then  record  a  corresponding  comparator 
--  trip.  IL_COMP_Vx(v) . 

--  Compare  each  voted  input  signal  with  the  associated  median 
--  value,  and  if  out  of  specification  tolerance,  not  a  comparator 
--  trip  in  IL_COMP_Vx(y) . 


begin  --  Procedure  MANAGE_IL_S£NSORS_V\ 


-  Add  Demonstration  Software  Here 


CHNL_x_XCHK_NU.M  5  : 

XCHK_SYNCH_x  ;  --  Call  for  N-Version  Vote 

end  MANAGE  IL  SENSORS  Vx  . 
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11.0  CALC  INNER  LOOP  PROCEDURE  SPECIFICATION 


A  pitch  inner  loop  stability  augmentation 
improve  the  inherent  flying  qualities  of 


control  law  shall  be  provided  to 
the  aircraft.  Since  a  negative 


static  stability  margin  is  assumed  for 
function  shall  be  regarded  as  critical, 
is  therefore  inherent  in  the  design,  with  graceful  degradation  of  performance 
under  most  multiple  fault  conditions. 


the  aircraft,  the  pitch  stability 
Double  fail-operational  redundancy 


11.1  Control  Law 


The  pitch  stability  augmentation  control 
analytical  block  diagram  presented  in 
arithmetic  shall  be  used. 


law  shall 
Figure  22 


be  in  accord  with  the 
No  extended  precision 


11.1,1  Signal  Shaping 


Digital  filtering  shall  be  used  (as  contraste 
for  example)  for  dynamic  signal  shaping.  The  sa 
accord  with  the  iteration  rate  in  Paragraph 
may  be  used  on  the  complex  frequency  operator 
delay  operator  as  appears  in  digital  filter  equations: 


wi 

th 

numerical  i 

ntegr 

at  ion . 

■  li 

ng 

interval  T 

shall 

be  in 
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.  1 . 

The  Tusti 
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s  , 

to 

obtain  z. 

the  c 
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11.1.2  Gain  Scheduling 


Sensor  signal  gains  shall  be  scheduled  as  a  function  of  true  airspeed  in 
accord  with  Figure  22.  In  the  event  that  the  true  airspeed  signal  is 
questionable,  i.e.,  if  both  components  of  IL_C0MP_Vx .  TAS_'.’AL  are  not  valid, 
all  gains  shall  revert  to  their  lowest  scheduled  values 


11.1.3  Outer  Loop  Command  Summation 

Vhen  externally  selected.  via  MODE_ENC_Vx  AUTOPILOT  -  A"71 LAND .  an  outer 
loop  pitch  servo  command,  AUTOLAND  CMDVx  shall  he  summed  with  “he  inner 
loop  command  as  shown  in  Figure  22. 

1 1 . 1 . A  Command  Limiting 

The  summation  of  the  inner  and  outer  loop  servo  commands  shall  be  limited  to 
-8.0,  +1.0  degree  of  stabilizer  displacement. 


The  inner  loop  control  law  shall  be  engaged  at  all  times,  but  it  may  be 
altered  externally  due  to  sensor  resource  depletion,  which  can  cause  a 
median  sensor  input(s)  to  clamp  to  zero. 


11.2.1  Mode  Engagement 

The  basic  stability  augmentation  function  shall  be  activated  as  a  function  of 
aircraft  electrical  power  on,  provided  the  respective  DFCS  channels  are  able 
to  commence  cycling  in  the  foreground  executive  program  (see  Section  a  .  0  i  . 
During  the  first  pass  through  the  control  law  following  power  application  or 
resumption,  the  high-pass  filter  for  angle -of -attack  shall  be  initialized  to 
set  its  output  to  zero  (past  difference  equation  output  to  zero,  and  past 
input  value  to  present  input  value'.  This  initialization  precludes  an 
engagement  transient. 


11.2.2  Stick  Command  Blending 


Each  of  the  pilots'  stick  command  inputs  shall 
degrees  of  stabilizer  command  deadband,  and 
obtain  an  averaged  input  value  The  result  -nt 
to  an  ■*-/-  12.5  degrees  of  stick  command. 


be  passed  through  a  0.05 
then  they  shall  be  summed  to 
command  shall  then  be  limited 


11.2.3  True  Airspeed  Validity 

The  true  airspeed  validity  signal,  IL_C0MP_Vx . TAS_VAL .  shall  be  used  to 
determine  that  the  true  airspeed  signal  is  acceptable  for  use  in  gain 
scheduling.  Both  validity  signals  must  be  True 


11.3  Signal  Interfaces 

All  input  signals,  with  the  possible  exception,  of  the  outer  I  t  o 
will  have  been  voted  prior  to  receipt  by  3AL3_I!‘NER_Li  to  eliminate 

discrepant  inputs  due  to  hardware  faults. 

11.3.1  Sensor  Inputs 

All  sensor  inputs  are  of  derived  types  Consequent  1 v  .  tvre  c o;r >■  r  , :  y-.  -  • 
Float  shall  be  performed  where  necessary.  e  g  .  prior  t  ->  signal  .re¬ 
conversions  . 

11.3.2  Steering  Command  Input 

The  outer  loop  steering  command  input  signal.  AL'TOLAN'D_CMD_'.'x  is  incremental 
about  the  stabilizer  trim  position  (which  is  irrelevant  to  the  implementation 
of  this  procedure).  Since  it  is  a  derived  type,  it  shall  he  converted  tc 
Float  type  for  control  law  computation. 


11.3.3  Logic  Inputs 


The  logic  inputs,  IL_COMP_'vx .  TAS_VAL  and  M0DE_ENG_7x  Al'TOPILO 
vector  and  a  record  enumeration  tvpes.  respective!.-. 


11.3.-*  Servo  Command  Output 

The  stabilizer  servo  command  output  signal  shall  be  conver 
type  to  the  derived  tvpe ,  STAB_COMMAND .  with  a  range  construi 
degrees . 


11.4  Program  Structure  Requirements 

From  a  static  standpoint,  CALC  INNER_LOOP  7x  is  incorpo 
program  structure  as  shown  in  the  call/usage  gr  iph  in  f- 
dynamic  standpoint,  the  multirate  executive  structure  it,  F 
CALC  INNER  LOOP  Vx ’ s  invocation. 


11.4.1  Iteration  Pate 


As  evident  in  Figure  1-* .  the  iteration  rat*-  tor 
20  Hz 


1 1  .  -»  .  2  Maximum  Corrputatnr:  Time 

As  indicated  in  Figure  IS  ,  the  maximum  allowable 
CALC_ INNER_LOOP_’.’x  is  6  milliseconds 

11.5  Input/Outrut 


IL  MED  Vx 


SENS  R  SET 


vpe  I L_S  ENSOR  _S  LI 
record 


A0A_DIS?L 

A  ■  A  S  • 

A  * . 

CP  STICK 

s  ,  4 

P_RATE 

ANG  RATE 

>>  I  1 ,  N 

P  STICK 

STICK 

pi 

TP _A IRS  PEED 

tas  s:  n 

A 1 . 

end 

record  , 

type 

ANG_RATE_SI(-NAL 

i  s 

new  FLOAT 

l  <i  I .  £  *-* 

type 

AOA  SIGNAL 

i  s 

new  FLOAT 

r  viiik’e 

type 

STICK  CMD 

i  s 

new  FLOAT 

r  -iii^ 

type 

TAS_SIGNAL 

i  s 

new  FLOAT 

r 

AUTOLAND  CMD  V3 


PITCH  COMMAND 


cvpe  PITCH_COMMAND  is  new  FLOAT  range  -3.6  , 

MODE_ENG_Vx  :  AFCS_SELECTION  . 

type  AFCS_SELECTION  is 
record 

AUTOPILOT  :  AP_SELECTICN  . 

AUTOLAND  :  AL_CATEGORY  . 

end  record  ; 

Cvpe  AP_SELECTION  is  (ALT_HOLD ,  AUTO LAN D .  BASIC.  VE 
type  AL_CATECORY  is  iCAT^l  CAT_2 .  CAT_3A.  OFF 

IL_COMP_Vx . TAS_YAL  :  PAIR_7ALID 

OUTPUTS  : 

STAB_S  ER70_CMD_Yx  S  T  A  B  _  C  0  MMA  N D  . 

type  STAB_COMMAND  is  new  FLOAT  range  • 1 1 . 0 . . 2 


■»-.  w-_  »V  V-.  \r-  V--.- -V  '.T'-- 


•r  wymymywywyvywyvyw  \rwv*ywyv  H<  V*V  Vs>  '.** 


Ada  Procedure  CALCINNER  LOOP  Vx 

with  DFCS_LOGIC  use 

with  DFCS_RE SOURCES  ;  use 

with  VOT I NG_ PLANES  .  use 

separate  t  CONTROL^ LAWS ' 
procedure  CALC _ INN ER_L00P_7x 

Local  Declarations  : if  anv i 

Place  Static  Variables  in  User -Defined  i’.tckaae  •  s 


DFCS_LOGIC  ; 

DFCS_RESOLRCES 

'.’OUI.NG_PLA.NES 

i  s 


--  the  inner  loop  control  law  commands  are  generated  from  'he 
-■  input  signals,  IL_MED_Vx  If  an  autopilot  mode  is  select? 
--  via  M0DE_ENG_’.’x.  the  autopilot  input  command  is  s. armed  wit 
--  the  inner  loop  command.  The  output  in  either  case  is 
--  STAB  SERVO  CMD  Vx 


begin 


••  Add  Demonstration  Software  Here 


CHNL_x_XCHK_NTM  -  h 

xchk’synch  x  . 


end  CALC  INNER  L’-  P  Vx 


12.0  ASSESS  SYSTEM  PROCEDURE  SPECIFICATION 


The  fault  logic  states  of  all  channels  shall  he  evaluated  to  ascertain  the 
status  of  the  total  system  with  respect  to  the  augmented  fifing  qualities  and 
the  operational  state  of  the  system.  Note  that  the  operational  state  implies 
a  lower  bound  on  flying  qualtities  level,  which  can  be  exceeded  for  non- 
normal  operational  states.  The  svstem  status  logic  should  be  consistent 
with  that  given  in  Figure  6  of  DOT  FAA.  CT-36  23,  but  the  following 
requirements  shall  govern.  None  of  the  following  logic  shall  latch,  ar.v 
such  effect  would  result  from  latching  of  input  logic  sitna.s  upstream  in  the 
data  flow. 


P 


r 


K 


l' 

t-: 


12.1  Fifing  Qualities  Status 

The  fault  status  of  the  augmented 
shall  be  evaluated  to  determine  fir 
following  logic  shall  be  implemented, 
TAS  denotes  true  airspeed' 

Normal  Flying  Qualities 

AND 

AND 

AND 


Degraded  Flving  Qualities- -> 

OR 

AND 

.AND 


Marginal  Flving  Qualities- -> 

AN  D 
AND 


flv-bv-wire  AF3W  sensors.  I  L_  V  M?_'.'x . 
ing  qualities  status.  FLY_2UAL_Yx .  The 
where  ,-s 0 A  denotes  a n z ~ e - o t -  a 1 1  a c  rt ,  and 


Both  True  Airspeeds  Tali  i 
Minimum  of  2  Associate:;  Stick 
Commands  Valid. 


i  Maximum,  of  1  Rate  Qvro  Valid 
Maximum  of  1  TAS  Valid 
Minimum  of  2  AOA  Pairs  Valia 
Minimum  of  2  Associated  Stick 
Commands  Valid 

Minimum  of  2  Rate  Vvr-s  .'a  1  :  i 
Max i mum  of  1  A ‘ A  Pairs  V  1 1  i  i 
Mini  mum  o  f  2  •'•.  s  s  o  c  i  a  t  e  i  S  t  . 
Commands  V  >  1  ;  i 


".da* 


The  fault  status  <:  the  auv'er 
the  status  ot  » 1  1  four  re¬ 
evaluated  to  determine  CO; 
availability  purposes  The  f 


Op  e  r  a  t  i  or.  1 1  State  1 
-Double  Fail  Operational 


ommar.ds 


Operational  State  2  -->  All  Rate  Gvros  Valid 

(Single  Fail  Operational)  AND  All  TAS  Valid 

AND 

((Exactly  3  AOA  Pairs  Valid 
AND  Minimum  of  3  Computer  Channels  Valid 
AND  [Minimum  of  3  of  One  Set  of  Stick  Commands 
Valid 

OR  Minimum  of  2  of  Both  Stick  Commands  Valid' ) 

OR  (Minimum  of  3  AOA  Pairs  Valid 
AND  Exactly  3  Computer  Channels  Valid 
AND  [Minimum  of  3  of  One  Set  of  Stick  Commands 
Valid 

OR  Minimum  of  2  of  Both  Stick  Commands  Valid] 

OR  (Minimum  of  3  AOA  Pairs  Valid 
AND  Minimum  of  3  Computer  Channels  Valid 
AND  [Exactly  3  of  One  Set  of  Stick  Commands 
Valid 

AND  Maximum  of  1  of  Other  Set  of  Stick  Commands 
Val  id 

CR  Exactly  2  of  Both  Sets  of  Stick  Commands 
Val id] )  ! 

Operational  State  3  - -> 

(Fail  Unsafe  ) 

(Exactly  2  AOA  Pairs  Valid 
AND  Minimum  of  2  Computer  Channels  Valid 
AND  Minimum  of  2  of  One  Set  of  Stick  Commands 
Valid) 

OR  (Minimum  of  2  AOA  Pairs  Valid 
AND  Exactlv  2  Computer  Channels  Valid 
AND  Minimum  of  2  of  One  Set  of  Stick  Commands 
Val id  > 

OR  (Minimum  of  2  AOA  Pairs  Valid 
AND  Minimum  ot  2  Computer  Channels  Valid 
AND  Exactlv  2  of  One  Set  of  Stick  Commands  Vali 
AND  Maximum  of  1  of  Other  Set  of  Stick  Corrm.ar.es 
Valid i 

Operational  State  -* 

(Effectively  Depleted 


Maximum  Allowable  Commit  a  t  i  or.  Time 


Maximum  of  1  ANA  Pair  Val: 
OR  Maximum  of  1  Computer  'bar: 
OR  Maximum  of  1  Stick  Oommai’.u 


r.h :  s 


The  maximum  allowable 
mill i seconds 


sub  - f  r  a me 


line  to: 


.  i  imp1 1  •  i 


|  INPUTS  | 


CHNL_STATUS_V1 ,  CHNL_STATUS_V2 , 

CHNL  STATUS  V3 ,  CHNL  STATUS  V4  •  BOOLEAN  ; 


IL_COMP_Vx 

type  I L_S ENSOR_S TATUS  is 
record 

AVG_AOA_VAL 
CP_STK_VAL 
LF_AOA_VAL 
P_STK_VAL 
P_RATE_VAL 
RT_AOA_VAL 
TAS_VAL 
end  record  ; 


IL  SENSOR  STATUS 


QUAD_VALIDITY  ; 
QUAD_VALIDITY  ; 
QUADJ/ALIDITY  ; 
QUAD_VALIDITY  . 
TRIAD_VALIDITY  ; 
QUAD_VALIDITY  ; 
PAIR_VALIDITY  ; 


|  OUTPUTS  | 


FLY_QUAL_Vx  :  FLYING_QUALITIES  ; 

cype  FLYING_QUALTIT.I ES  is  (UNFLYABLE,  MARGINAL. 

FBW_STATUS_Vx  :  PRI_FCS_STATUS  ; 

cype  PRI_FCS_STATUS  is  (0P_STATE_4,  OP_STATE 

OP_STATE_l )  ; 


DEGRADED,  NORMAL) 


3,  OP_STATE  2, 


Ada  Procedure  ASSESS_SYSTEM_Vx 

with  VOTING_PLANES  ;  use  VOTINGPLANES  ; 
separate ( DFCS_LOGIC) 
procedure  ASSESS_SYSTEM_Vx  is 

Local  Declarations  (if  any) 

Place  Static  Variables  in  User-Defined  Package(s) 


--  U-sing  fault  logic  inputs  CHNL_V1,  CHNL_V2 ,  CHNL_V3 ,  and  CHNL_V4 
--  along  with  IL_COMP_Vx,  compute  the  system  states,  FLY_QUAL_Vx  and 
--  FBW_STATUS_Vx ,  per  the  logic  requirements  in  the  English 
--  language  part  of  the  specification. 


begin 


Procedure  ASSESS  SYSTEM  Vx 


--  Add  Demonstration  Software  Here 


CHNL_x_XCHK_NTJM  7  ; 

XCHK  SYNCH  x  ;  --  Call  for  N-Version  Vote 


end  ASSESS  SYSTEM  Vx  ; 


13.0  GIVE  WARNING  PROCEDURE  SPECIFICATION 


Warning  display  output  signals  shall  be  generated  based  on  internal  mode  and 
fault  logic  variables  to  indicate  control  function  status  and  availability. 
Information  shall  be  displayed  only  when  appropriate  to  inform  the  flight 
crew;  this  corresponds  to  warning  logic  conditions  other  than  "BLANK." 


13.1  Autoland  Status 


The  autoland  status  output,  WARN_Vx . AUTO LAND ,  shall  directlv  reflect  the 
logic  input  signal,  AL_WARN_Vx,  for  both  are  of  the  same  type. 


13.2  Augmented  Flv-Bv-Wire  (AFBW)  Status 

The  AFBW  status  output,  WARN_Vx . FLY_BY_WIRE ,  shall  reflect  the  logic  input 
signal,  FBW_STATUS_Vx ,  with  the  input  state  0P_STATE_1  mapping  to  BLANK. 


13.3  Flying  Qualities  Status 

Flying  Qualities  status,  WARN_Vx . FLYING_QUAL,  shall  reflect  the  input  logic 
signal,  FLY_QUAL_Vx,  with  the  following  correspondences; 

IMPAIRED_FQ  -->  Degraded  Flying  Qualities  OR 

Marginal  Flying  Qualtities  OR 
Unflyable  Flying  Qualities. 

BLANK  -->  Normal  Flying  Qualities. 

13.4  Master  Warning  Indicator 

Each  time  a  new  warning  state  is  first  annunciated,  a  master  warning  signal, 
FLASH_WARNING_Vx ,  shall  be  set  to  BLINKING.  When  acknowledged  bv  an 

externally  applied  Boolean  variable  ACKNOWLEDGE  being  momentarily  set  to 
True,  FLASH_WARNING_Vx  shall  be  set  to  STEADY,  where  it  shall  remain  until  a 
new  warning  is  generated,  or  all  prior  warnings  are  terminated  via  the  input 
logic  to  this  procedure.  When  no  warnings  exist,  FLaSH_WARNING_Yx  shall  be 
set  to  OFF. 


13.5  Maximum  Allowable  Computational  Time 


The  maximum  allowable  sub- frame  time  for  this  computation  shall  be  2 
milliseconds . 


|  INPUTS  ! 


AL_WARN_Vx  :  AL_STATUS  , 

Cvpe  AL_STATUS  is  (CAT_2_IN0P,  CAT_3_IN0P,  OFF)  ; 

F  BW_  S  TATU  S  _Vx  :  PRI_FCS_STATUS  ; 

type  PRI_FCS_STATUS  is  (0P_STATE_4,  OP_STATE_3,  0P_STATE_2 .  OP_STATE_l ) 
FLY_QUAL_Vx  :  FLYING_QUALTITIES  ; 

type  FLYING_QUALTITIES  is  (UNFLYABLE,  MARGINAL,  DEGRADED,  NORMAL)  ; 
ACKNOWLEDGE  :  BOOLEAN  , 


|  OUTPUTS  | 

WARN_Vx  :  WARNING_STATE  ; 

type  WARNING_STATE  is 
record 

AUTOLAND 
FLY_BY_WIRE 
FLYING_QUAL 
end  record  ; 

type  FBW_STATUS  is  (0P_STATE_4,  OP_STATE_3 ,  OP_STATE_2 ,  BLANK) 
type  FQ_STATUS  is  ( IMPAIRED_FQ ,  BLANK)  ; 

FLASH_WARNING_Vx  :  MASTER_WARN  ; 

type  MASTER_WA RN  is  (BLINKING,  STEADY,  OFF)  ; 


AL_STATUS  ; 
FBW_STATUS  ; 
FQ_STATUS  ; 


Ada  Procedure  GIVE  WARNING  Vx 


with  VOTING_PLANES  ;  use  VOTING_PLANES  ; 
separate (DFCS_LOGIC) 
procedure  GIVE_WARNING_Vx  is 

Local  Declarations  (if  any) 

Place  Static  Variables  in  User-Defined  Package(s) 


--  Using  the  inputs  AL_WARN_Vx,  FBW_STATUS ,  Vx ,  and  FLY_Ql'AL_Vx , 

--  compute  the  appropriate  outputs  to  the  Warning  Display, 

--  WARN_Vx,  and  in  turn,  the  Master  Warning,  FLASH_WARNING_Vx ,  per 
--  the  logic  given  in  the  English  text  part  of  the  specification. 

--  The  Boolean  input  ACKNOWLEDGE  should  cause  the  Master  Warning  to 
--  glow  steadily,  rather  than  continue  flashing  as  should  occur 
--at  the  onset  of  a  new  warning. 


begin 


Procedure  GIVE  WARNING  V 


--  Add  Demonstration  Software' Here 


CHNL_x_XCHK_NUM  8  ; 

XCHK_SYNCH_x  ;  --  Call  for  N-Version  Note 

end  GIVE  WARNING  Vx  ; 
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14.0  TEST  HARNESS  SET-UP 


Although  ic  was  planned  that  the  testing  of  the  software  fault-tolerant  DFCS 
be  done  sequentially  in  non-realtime  on  a  VAX  computer,  it  was  understood 
that  the  four  versions  of  demonstration  software  would. would  normally  reside 
in  a  quadruplex  DFCS  architecture.  Hence,  four  parallel  channels  with  double 
fail-operational  capability  were  assumed.  along  with  appropriate 
sensor/effector  redundancy.  Note,  however,  that  the  test  harness  software 
itself  is  mostly  single  string.  The  overall  program  organization  to 
mechanize  all  this  is  shown  in  Figure  23;  here  only  Tasks  DFCS_x_EXEC  and 
CHNL_x_SYNCH  are  replicated  four  times,  because  they  interface  with  the  four 
DFCS  channels.  All  of  the  DFCS  software,  moreover,  is  effectively  contained 
within  Tasks  DFCS_x_EXEC  in  the  Figure  23  representation. 

The  test  harness  runs  interactively  on  a  non-realtime  basis,  with  test  cases 
applied  through  files  readable  by  the  test  program.  Considerable  flexibility 
exists  to  expand  the  variety  and  extent  of  testing  possible,  but  currently, 
the  primary  testing  mode  is  customary  airplane  closed-loop  simulation.  The 
DFCS  software  is  incorporated  in  the  test  harness  as  shown  in  Figure  24  for  a 
typical  channel.  All  of  the  program  units  shown  belong  to  the  DFCS  except 
for  the  three  shaded  ones.  As  previously  stated,  the  calling  of  Procedure 
RUN_F0REGR0UND_x  in  the  test  harness  is  done  by  Task  DFCS_x_EXEC  in  the  test 
harness,  rather  than  by  Procedure  RUN_DFCS_EXEC  in  the  actual  DFCS  software 
load  module.  Also,  Procedure  V0TE_RESL'LTS  is  called  by  the  test  harness 
rather  than  by  the  DFCS  software. 


14,1  Test  Harness  Operation 

At  the  outset  of  testing,  the  top-level  program,  Procedure  RUN_TEST_EXEC . 
makes  procedure  calls  to  SELECT_0PTI0NS  and  APPLY_INPUTS  to  initalize  testing 
(see  the  listing  in  Figure  25a)  based  on  prompted  selections  by  the  user. 
Following  this  Procedure  START_TESTING  (see  the  listing  in  Figure  25b)  is 
invoked  by  RUN_TEST_EXEC ,  and  actual  testing  ensues  when  entry  is  called  to 
each  of  the  four  DFCS_x_EXEC  tasks  (see  the  body  part  listing  for  Package 
TEST_RESOURCES  in  Figure  25c)  .  Normal  testing  then  proceeds  primarily  under 
the  control  of  Task  TEST_EXEC  (see  the  listing  in  Figure  25d) .  For  each  test 
cycle,  it  calls  Procedure'  APPLY_INPUTS .  As  indicated  in  its  source  code  in 
Figure  25e,  this  procedure  can  effect  open  or  closed  loop  testing  and  faulted 
or  fault  free  testing  for  a  predefined  number  of  cycles.  Sensor  and  logic 
inputs  can  be  altered  independently. 

Once  a  voted  DFCS  procedure  called  by  Procedure  RUN_F0REGR0l'ND_x  completes, 
it  calls  Procedure  XCHK_SYNCH_x  as  listed  in  Figure  25f.  These  four  DFCS 
procedures  are  the  only  ones  modified  whatsoever  for  test  harness  use. 
Basically,  cross -channel  voter  synchronization  would  probably  involve 
hardware  oriented  instruction  that  would  be  cumbersome  to  run  on  a  general 
purpose  computer.  Furthermore,  the  effort  would  be  difficult  to  justify  for 
the  type  testing  undertaken  here.  These  procedures  still  perform  the  type 
conversions  and  voted  value  corrections  as  required  in  the  DFCS  application, 
but  they  make  entry  calls  to  test  harness  task,  CHNL_x_SYNCH ,  as  defined  in 
Figure  25g. 


RUN 


Figure  23  ~  Overall  Test  Program  Call  Graph 
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Figure  25a  -  Test  Harness  Program  Unit  Listing 
Procedure  RUN  TEST  EXEC 
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Figure  25b  -  Test  Harness  Program  Unit  Listing 
Procedure  START  TESTING 
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Figure  25c  -  Test  Harness  Program  Unit  Listing 
Procedure  APPLY  INPUTS 
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It  Vcrt-Tll'tOUT  tnen 

put-line ("Abnormal  Vote  Fortncoming" )  ; 
else  put. line  C "normal  Vote  For tncoming " )  ? 

ena  if  ; 

VQTE-RfcSdLIS  (CC-HEF.PT ,  CC_R£.SULTS)  ; 
if  CC-KfcSUL'fS  /=  lD£AL_VUTi:  tnen 

ASSESS. VGTt (CC-F£F.PT,  CC-HESULIS)  ; 

end  if  ; 

lil.'N.VOTFo  t!  bUM-VuTKS  t  1  * 
it  M',,‘_VOTfc:S  >=  r'AX-Vu’ftS 

tnen  UtiuFS  I  -  d uM—  LOUP 5  +■  1  } 

vu ifc.S  :=  u  ; 

it  hilil-.LuuPS  <  FAX-L<-)UP3 

tnen  appl  i-lhr-ij  rs  ; 

else  HlJ.4iJlbo  :=  false  ; 

CH  «L«.l— SYI-.CH  ,  UtSUi't  ; 

Cri.xL— 2— SY-MCm •  KtSL'iE  ; 

CHi»L— 3—w»/bCn.Ht5u/-F  } 
CHi‘t.-4.SYwCh.«'cSUrie.  ; 
exit  AUTO-TESTING  ; 

end  If  ; 

ena  it  ; 

-«  Moving  to  wext  Voting  Plane 
if  CHfiL„«KAOYll)  tnen 

CH.4L-1-SYNCH. RESUME  ? 

end  if  ; 

it  CHml.kKADK (2)  then 

ChiJL-2-SYNCil.riESUME  ; 

ena  if  ? 

if  CHriL.READY ( 3)  tnen 

C ri in L<— 3— S Y 1  i v»r\ »  P t SU  ** E  } 

era  it  ; 

it  C m  i ;  L.  a  £  A  u  Y 1 4 )  tnen 

Cri.4u-4.Sr  ICrf.HcSunE  ; 

era  if  ; 

ena  looo  Au TO— TFSTInG  ; 

—  lest  of  Foreground  Complete 

exception 

v n e .1  V. R o  14 G—  F Ij A n t  =  > 

put-line ( "nod  Synchronization")  ; 

era  TEGT-riXiC  ; 
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Including  the  top-level  program  for  the  N-version  demonstration,  Procedure 
RUN_TEST_EXEC ,  ten  Ada  tasks  are  active  from  the  outset  of  program  execution. 
These  include  the  four  test  harness  DFCS  executive  programs,  Task 
DFCS_x_EXEC,  four  secretary  tasks  that  regulate  voting  plane  synchronization, 
Task  CHNL_x_SYNCH ,  and  the  test  coordinator,  Task  TEST_EXEC.  The  secretary 
tasks  needed  to  effect  a  four-way  synchronization  using  Ada  inherently  two- 
way  rendezvous.  These  tasks  are  declared  in  Package  TEST_RESOURCES  per 
Figure  25c.  Intertask  communication  as  depicted  in  Figure  26  continues  so 
long  as  the  master  control  Boolean,  RUNNING,  is  True. 

Initially,  entries  to  Tasks  DFCS_x_EXEC  are  called  from  Procedure 
START_TESTING ,  namely,  DFCS_x_EXEC . ENGAGE  for  each  of  the  four  channels.  As 
each  voted  DFCS  applications  procedure  completes,  the  associated  Procedure 
XCHK_SYNCH_x  calls  entry  to  the  corresponding  secretary  tasks  with  a 
CHNL_x_SYNCH . READY  statement.  When  the  CHNL_x_SYNCH  accepts  the  entry  call 
and  relays  it  to  Task  TEST_EXEC,  both  DFCS_x_EXEC  and  CHNL_x_SYNCH  are 
suspended.  Then  the  other  channel  tasks  are  activated  one  by  one  until  all 
have  reported  in  to  TEST_EXEC's  timed  select  loop  that  accepts 
TEST_EXEC . CHNL_x_READY  entry  calls.  After  checking  to  ensure  that  all  DFCS 
channels  are  at  the  correct  voting  plane,  Task  TEST_EXEC  calls  Procedure 
VOTE_RESULTS  and  analyzes  and  records  the  results. 

TEST_EXEC  then  checks  for. additional  test  case  selections.  If  so,  it  calls 
applies  them  and  one  by  one  releases  DFCS  channels  for  the  next  test  cycle. 
This  is  done  by  a  CHNL_x_SYNCH . RESUME  entry  call  that  completes  two 
rendezvous  and  permits  DFCS_x_EXEC  to  become  active  again.  The  next  DFCS 
applications  module  in  RUN_FOREGROUND_x  is  then  executed,  and  the  next  voting 
plane  is  sought  via  a  repeat  of  the  four-way  synchronization  process.  If 
Task  TEST_EXEC  determines  that  all  test  has  been  completed,  it  sets  RUNNING 
to  False  and  terminates.  The  rest  of  the  tasks  then  terminate  as  well. 


The  closed-loop  simulation  set-up  is  depicted  in  Figure  27  in  a  state 
variable  form  that  coincides  with  the  external  DFCS  sensor/effector  signal 
interfaces.  The  source  code  for  the  simulation  is  presented  in  Figure  28. 
Basically,  it  reads  in  flight  case  data  from  an  interactively  named  file, 
trims  the  airplane  under  selected  conditions,  and  commences  to  generate  the 
array  of  inner  and  outer  loop  sensor  signals  based  on  the  input 
STAB_SERVO_CMD_x.  The  output  signals  undergo  data  type  and  scaling  changes  as 
appropriate.  Signal  fan-out  for  multiple  sensors  and  fault  insertion 
faculties  reside  in  Procedure  UPDATE_SENSORS ,  which  is  also  called  by 
Procedure  APPLY_INPUTS  per  Figure  23. 


During  DFCS  software  versions,  the  test  harness  was  modified  for  single 
channel  use.  Basically,  this  involved  disabling  all  but  one  particular 
channels  tasks,  and  tailoring  input  test  data  for  limited  scope  or  unit 
testing.  Some  data  object  visibility  problems  were  encountered  that 
necessitated  selective  raising  of  the  variable  namespace  so  that  the  test 
harness  could  import  and  access  certain  variables.  Basically,  the  test 
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harness  could  import  and  access  certain  variables.  Basically,  the  test 
harness  was  readily  usable,  and  naturally  provided  all  the  Ada  package 
objects  needed  for  testing.  Test  case  definition  was  problematical  because 
of  the  data  dependencies  among  applications  program  units,  but  test  case 
application  via  the  harness  was  quite  convenient. 


14.5  Compilation  Dependencies 


The  total  DFCS/test  program  is  exceptionally  complex  for  its  lines  of  source 
code  because  of  the  N-version  voting  requirements  and  the  test  observability 
requirements.  While  the  procedure/task  calling  structure  in  Figure  23  is 
rather  straightforward,  the  compilation  dependencies  are  quite  tortuous,  as 
Figure  29  reveals.  They  can  complicate  recompilation  following  essentially 
minor  code  changes.  These  dependencies  are  inherent  in  Ada,  and  they  are  the 
price  of  global  consistency  checks  among  program  units.  This  figure, 
however,  makes  it  clear  what  recompilation  sequences  are  required,  and  hence 
facilitates  orderly  software  development. 


The  all-up  test  harness  was  run  with  a  modest  amount  of  further  development. 
Despite  prior  awareness  of  the  criticality  of  specifications  (e.g.,  see 
Reference  11) ,  several  iterations  of  specification  de-bugging  were  necessary 
to  eliminate  associated  software  faults.  The  Ada  program  structuring 
techniques  seemed  to  work  well, "with  the  exception  of  raising  the  visibility 
level  of  many  variables  for  test  observability  or  N- version  voting.  The 
software  fault  tolerance  seemed  to  work  well,  but  further  study  of  the  voter 
mechanisms  is  indicated. 

Since  some  of  the  programmers  had  no  prior  Ada  experience,  the  incidence  of 
software  faults  was  somewhat  high.  But  all  considered,  programmer  usage  of 
Ada  was  really  quite  good.  Variations  among  versions  was  very  substantial, 
alleviating  concern  that  Ada  restrictions  would  hamper  independence  of 
software  versions.  The  richness  of  Ada  admits  diverse  ways  of  implementing 
the  same  functionality,  provided  the  encompassing  design  does  not  encroach 
beyond  program  unit  interfaces.  This  means  that  N-version  programmers  must 
have  freedom  to  define  and  control  all  data  objects  at  the  level  they  are 
developing,  a  rule  that  was  learned  by  early  and  unsuccessful  initiatives  to 
the  contrary. 

A  summary  critique  of  the  effort  is  presented  in  Figure  30,  and  expanded  in 
the  following  sub  -  sections , 


Basically,  the  N-version  demonstration  was  satisfactory.  Ample  faults 
indigenous  to  the  four  versions  permitted  affirmation  of  the  fundamental 
adequacy  of  the  N-version  approach,  but  some  questions  remain  due  to  the 
limited  scale  evaluation  possible.  Still,  the  degree  of  complexity  of  the  N- 
version  software  was  surprisingly  high,  largely  due  to  mode  and  fault  logic. 
The  problems  with  the  specifications  resided  mostly  in  this  area  as  well. 
The  preparation  of  adequate  specifications  was  found  to  be  especially  prob- 
lemsome.  Hence,  our  continuing  interest  in  formal  specification  has  been 
intensified.  Larger-scale  logic  definition  problems  may  dictate  some  new 
type  verification  tools  with  respect  to  correctness  and  completeness. 


In  the  course  of  N-version  development,  it  was  also  discovered  that  the  top- 
level  design  had  been  too  encompassing.  For  example,  the  definition  of  data 
types  and  objects  for  the  applications  programs  units  was  found  to  be  best 
left  to  the  •  individual  programmer's  discretion.  This  enabled  greater 
independence  among  versions  and  better  overall  program  structure.  At  the 
same  time,  the  low-level  N-version  programmer  defined  packages  were  found  to 
be  very  useful  in  a  variety  of  ways,  such  as  containing  saved  variables  and 
text  for  newly  defined  procedures.  The  ultimate  variation  among  versions  was 
appreciable,  alleviating  concerns  that  Ada  would  be  too  restrictive. 


Basically,  the  Ada  package  partitioning  technique  produced  qualitatively  good 
results  in  limited  use.  Certain  benefits  accrue  to  source  code  compactness 
and  comprehensibility.  For  example,  the  way  in  which  data  objects  were 
declared  obviated  the  need  for  the  N-version  program  units  to  have  parameters 


passed  to  them,  thereby  making  the  source  code  for  Procedure  RUN_FOREGROUND_x 
far  less  cluttered  than  it  otherwise  would  be.  Had  it  not  been  for  the 
raising  of  the  namespace  for  voting  or  testability,  this  absence  of  parameter 
passing  would  have  been  accompanied  by  reductions  in  the  data  object 
namespace.  Specifically,  some  of  the  objects  would  have  been  declared  in 
package  bodies,  rather  than  in  specification  parts. 

The  same  package  definition  approach  lent  itself  to  "detached"  test  harness 
observability  of  the  voted  DFCS  data  objects  in  that  the  DFCS  code  was 
unaffected  by  the  test  harness  except  for  certain  object  visibility 
elevations.  This  passive  observation  capacity  is  of  course  inherent  in  the 
Ada  language.  For  unit  checkout/de -bugging,  the  test  harness  was  set  up  to 
run  for  just  one  DFCS  channel  task.  This  worked  well,  but  it  prompted 
concern  over  unit  testing  in  Ada  in  general.  Basically,  access  to  the 
entities  required  of  all  interfacing  program  units  seems  to  complicate  unit 
testing.  Since  the  single  channel  test  harness  alleviated  such  problems, 
perhaps  this  type  tool  may  prove  widely  useful. 

Despite  the  relatively  modest  size  of  the  overall  program,  a  significant 
effort  was  involved  in  coping  with  compilation  dependencies  among  Ada  units. 
Such  dependancies  are  complicated  in  the  combined  DFCS/test  software.  More 
generally,  they  are  the  price  of  Ada's  global  syntax  checks,  so  the  only 
alternative  is  the  purposeful  improvement  of  program  structuring  relative  to 
compilation  dependancies.  This  was  accomplished  using  graphical 
representations  of  the  kind  illustrated  in  Ref.  17.  This  technique  yielded 
the  perspective  to  lower  the  levels  of  some  dependencies.  It  also  made 
recompilation  demands  more  apparent.  Based  on  this  experience,  it  would  seem 
appropriate  to  include  compilation  dependencies  in  the  characterization  of 
Ada  program  structuredness. 


The  test  harness  was  surprisingly  compact  and  extensible,  as  well  as  very 
serviceable.  Although  the  harness  met  essentially  all  of  its  requirements,  it 
was  necessary  to  modify  the  test  article  software  at  the  lowest,  hardware  - 
oriented  level.  This  was  considered  reasonable  in  the  absence  of  target 
computers,  for  the  tradeoffs  for  simulating  synchronization  hardware  was  very 
unfavorable.  Note  that  testing  the  software  in  flight  computers  would 
normally  enable  visibility  of  any  address  location,  independent  of  program 
structuring  of  the  namespace.  This  suggests  that  the  raising  of  the 
namespace  for  test  observability  purposes  might  not  be  necessary  under  a  dif¬ 
ferent  testing  senario.  This  issue,  together  with  the  Ada  unit  testing 
question,  prompts  further  investigation  into  Ada  testing  techniques. 

To  date  the  test  harness  usage  has  been  somewhat  limited  compared  with  its 
potential.  The  test  driver  and  test  instrumentation/monitor  are  inherently 
adaptable  and  are  being  augmented  for  protracted,  multiple  test  cases.  The 
aforementioned  DFCS  logic  complexity,  in  part,  motivates  this,  along  with  the 
prospect  of  probing  for  persistent  software  faults.  These  are  of  major 
concern  because  they  are  the  kind  that  software  fault  tolerance  must  cope 
with.  Another  pending  use  of  the  harness  is  a  proposed  investigation  of  N- 
version  voters. 


w 


$53? 


The  following  conclusions  have  been  formulated  as  a  result  of  this  project: 

o  Calibration  of  benefits  of  N-version  software  are  needed  that 
quantitatively  validate  its  favorable  impact  on  system  reliability 

o  Complexity  metrics  are  needed  to  quantitatively  delineate  design  techniques 
or  alternatives  relative  to  program  structure 

o  Means  to  characterize  the  overall  structure  of  Ada  programs  are  desirable 
that  acknowledge  compilation  dependancies 

o  Ada  testability  needs  to  be  explored  in  terms  of  data  object  visibility 
versus  preferred  program  structuring  alternatives 

o  Specification  technology  needs  to  be  improved  to  facilitate  orderly  fi¬ 
vers  ion  software  development  and  preclude  specification  oriented  faults. 

Despite  the  extent  of  these  follow-on  recommendations,  the  investigation 

results  were  quite  favorable  with  regard  to  improved  structuring  techniques, 

high-fidelity  multitasking  testing,  and  N-version  software  implementation. 

The  identification  of  further  needs  are  actually  an  indication  of  progress. 
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Appendix  A  -  Version  3  Applications  Software 


Altogether,  six  versions  of  DFCS  applications  software  were  generated. 
Ultimately,  two  were  required  for  specification  de-bugging.  The  following 
version  is  provided  as  an  example  of  the  Ada  source  code  produced.  Note  that 
the  programmer  defined  Ada  packages  were  a  key  to  approaching  version 
independence  in  that  any  desired  data  types  or  objects  could  be  declared 
there.  Also,  the  packages  permitted  the  definition  of  saved  variables  as 
needed  for  digital  filters  or  logic  latches,  and  the  shortening  of  procedure 
bodies  by  distributing  source  code.  The  sequence  of  program  unit  listings  in 
this  appendix  is : 

Figure  No, 

Title 

Page 

A- 1 

Procedure  SELECT_M0DE_V3 

A-2 

A-2 

Procedure  ASSESS_CHANNEL_V3 

A-4 

A-3 

Package  CHNL_3_ASSESSMENT 

A-8 

A-4 

Procedure  GIVE_STATUS_V3 

A-9 

A-  5 

Procedure  MANAGE_AL_SENS0RS_V3 

A- 10 

A-6 

Package  CHNL_3_AL_V0TER 

A-12 

A-7 

Procedure  CALC_AUT0LAND_V3 

A- 17 

A-8 

Package  AL_RESOURCES 

A- 18 

A-9 

Procedure  MANAGE_IL_SENS0RS_V3 

A-24 

A- 10 

Package  CHNL_3_IL_V0TER 

A-  26 

A- 11 

Procedure  CALC_INNER_L00P_V3 

A-  30 

A-12 

Package  IL_RESOURCES 

A-  33 

A- 13 

Procedure  ASSESS_SYSTEM_V3 

A-  34 

A-14 

Procedure  GIVE_WARNING_V3 

A-  37 

A- 15 

Package  WARNING_CHECKS 

A-  38 

Ada  procedure  SFLFCT.muDE.  V3.ADA 


with  VOTING. PLANES  ;  use  VOTING.PL A NFS  ; 
separate C DECS. LOG 1C) 
procedure  SELECT.MOUE.V3  is 

beoin 

AL.W ARN.V  3  :=  BLANK  i 


case 

MODE.SEL. 

AUTOPILOT 

1  S 

when 

alt.hold 

=  > 

MUDE.fcNG.V3.AUT0Pir.0T 

= 

ALT.HOLD  ? 

MODE.ENG.V  3. AUTOLAND 

= 

OFF  ; 

wnen 

BASIC 

=  > 

MQDE.fcNG.V3. AUTOPiLuT 

= 

SASIC  ; 

MQDt.ENG.V 3. AUTOLAND 

= 

OFF  ; 

wnen 

JFE 

=  > 

MODE.ENG.V 3. AUTOPILOT 

= 

OFF  ; 

MODE.ENG.V  3 . AUTOLAND 

= 

OFF  ; 

when 

VERT-NAV 

=  > 

MODfc.ENG.V  3. AUTOPILOT 

= 

VFHT.MAV  ; 

MOnE.fcNG.V  3 .autoland 

OFF  ; 

wnen 

AUTOLAND 

=  > 

autoland.engagf.logic  ! 
declare 

tyre  VALIOTTY.CNT  is 
record 

GS  :  INTEGER  range  0..4  :=  o  ; 

na  j  integer  ranoe  0..3  o  ; 

RA  :  INTEGER  ranoe  0..4  :«  0  ; 

end  record  ; 

nun.val  j  validity.cnt  ; 

beoin 

WODE.SEL. AUTOPILOT  !  =  AUTOLAND  } 
for  INDEX  In  1..4 
loop 

if  AL.COMP.V  3 . G5.BEAN.VAL (INDEX )  =  TRUF 
then  num.val.GS  :=  num.val.GS  ♦  1  ; 
end  1  £  ; 

If  AL.CQMP.V3 .RAD.ALT.VALCINOEX)  =  IRU^ 
then  num.val.RA  : =  nmh.val.RA  ♦  i  ; 
end  if  ; 

If  INDEX  /s  4 

then  if  AL.C0MP.V3.N_ACCEL.VALf IND^X)  =  THU 
then  num.val.na  :=  num_vaL.na  ♦  l  ; 
end  if  ; 
end  if; 
end  loop  ; 
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e«it  NQoe.sFL. autolano  is 

•nen  CAT.JA  ■> 

It  FRu.STATUS.V J  *  OP.STAIE.l  ana  NUN.VAL.MA  a  i 

too  NUM_VAL.es  =  4  and  NUM.VAL.RA  ■  4 
tn«n  NOOE.ENC.VJ.AUTOLAND  :*  CAT.JA  I 
elllf  FRM.STATUS.V J  >*  op.state.2  and  NUN.VAL.MA  >S 
,no  NUM_VAL.es  >■  2  and  NUM.VAL.RA  >*  2 

tnen  Maor_F«e_vj.AtnnLANO  t*  cat.2  ; 

AL.MARN.VJ  l»  CAT. J.1NOP  S 

•lilt  FBm.STATUS.VJ  <  OP.STATE.2  or  nUn.VAL.NA  *  1 
or  NUM_VAL.es  a  I  or  NUN.VAL.MA  *  I 
than  mode.eno.v j. autoland  CAT-1  t 

AL.MARN.V5  :»  CAT. J.XNOP  ; 
all*  NODF.ENC.V J . AUTOL AND  »»  OFF  I 

AL.MARN.VJ  *»  CAT.J.XNUP  t 
end  It  j 
•nan  CAT-2  *> 

It  F8m.STATUS.VJ  >»  OP.STATE.2  and  NUN.VAL.MA  >«  2 

and  num.vaL.CS  >■  2  and  num.vaL.Ra  >■  2 
tntn  node. enc_v j, autoland  i»  cat.2  ; 

elslt  F8M.STATUS.V J  <  UP.STATE.2  or  NUM.VAL.NA  «  J 
or  NUM_VAL.es  »  1  or  NUM.VAL.RA  *  1 
cnan  NOOE.ENC.V J. AUTOLANh  j*  CAT_1  ; 

AL.MARN.VJ  l»  CAT.2. INOP  I 
elsa  mOOE.ENC.v J . AUTOL AnD  t»  OFF  i 
AL.MARN.VJ  l>  CAT.2— i NOP  > 
end  It  I 
«nen  CAT.I  *> 

It  NUN.VAL.NA  >»  J  and  NUM.VAL.es  >*  1 

and  NUM.VAL.RA  >*  1 

than  MOOF.ENC.VJ.AIITOLANO  »»  CAT-l  t 
alsa  MOOE.ENC.V J. AUTOLAND  I  a  OFF  ; 
and  It  ; 
enen  OFF  »> 
null  ; 
and  case  ; 

end  AuTQLANO.ENr.ACF.LOeiC  I 
and  case  ; 

chml.j.achm.num  ii  i  s 

xChk.lYnCh.J  j  —  call  tor  N-verslon  Vote 

and  5tLECT.M00E.VJ  » 
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V  v  •  .  V  V  >  V  V  V  ’.«*■>  V  »  V  '  •  • ,  AA.NjA  ,s  ,N  .V  .■> 


Ada  Procedure  ASSESS-CHANNFL-V3 


with  CHNL-3-ASSESSMENT  ;  use  CHNL-3. ASSESSMENT  ; 
Witn  CHANNEL-RESOURCES  }  use  CHANNEL-RESOURCES  ; 
separate (DECS-LOGICJ 
procedure  ASSESS-CHANNEL-V3  is 

beqin 


case  CPU-COUNi  is 
when  0  => 

If  CMPTR-3 . CPU-CHK-OK  =  FALSE 
then  CPU-CHK  l~  FALSE  i 
CPU— count  :=  l  ; 
end  if  ; 
when  1  => 

if  CMPTR-3. CPU-CHK-OK  =  TRUE 
then  CPU_cnuNT  :  =  -1  ; 
end  if  ; 
when  -10. .-1  => 

if  CMPTR-3. CPU-CHK.OK  =  TRUE 
then  CPU-COUNT  :*  CPU-COUNT  -  1  ; 
if  CPU-COUNT  <=  -10 
then  CPU— HEAL  5*  CPU-HEAL  ♦  1  ? 
If  CPU-HEAL  >  5 


--  Computer  Channel 
--  Normal 


- -  Faulted 


then  CPU-COUNT 
else  CPU-CHK 

CPU-COUNT 
end  if  ; 
end  if  : 

else  CPU-COunt  :  =  -1  ; 
end  If  ; 
when  2  => 

CPU-CH*  :=  FALSE  } 
end  case  ; 


=  2  t 
=  TRUE  ; 
s  0  ; 


Heal Inn 


--  Failed 


case  inp-cnuNT  is 

»n*n  o  => 

if  CMPTR-3. iO-PROC-OK  =  FALSF 
then  I0P-CMK  JS  FALSF  ; 

inp-COUNT  :=  l  i 
end  if  ; 
when  i  =  > 

if  CMPTR-3. IO-PROC-OK  =  TRUE 
then  iop-COunt  :=  -l  ; 
end  if  ; 


I/O  Processor 
--  Normal 


Faulted 
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Healim 


whan  -10. .-1  => 

if  CMPTR.3. 10-PR0C.0K  =  TRUE 

then  iop.count  :  =  top-count  -  l  ,* 

if  IOP.COUNT  <=  -10 
then  IQP.HEAL  !=  TOP-HEAL  ♦  1  ,* 
if  IOP.HEAL  >  5 

then  IOP.COUNT  :=  2  ? 

else  IOP.CHK  :=  TRUE  ; 

iop.count  :=  0  ? 

end  if  ; 
end  if  ; 

else  xop-COUnt  :  =  -l  ; 
end  if  ; 
when  2  => 

IOP-CHK  :  =  FALSE  } 
end  case  ? 

case  MUX-COUNT  is 
when  0..2  => 

if  MUX-COUNT  =  0 

then  if  omptR-3 . wUX.RUS.OK  =  fr'ALSE 
then  mux.COIINT  !*  1  i 
end  if  ; 

else  if  CMPTR-3.MUX-BUS.OK  =  FALSE 

then  mux-COUNT  t~  MUX-COUNT  ♦  1  i 
If  MUX-COUNT  >*  3 
then  MUX.CHK  :*  FALSE  i 
end  if  ; 

else  mux-COUNT  :s  o  ; 
end  if  ; 
end  It  ; 
when  3  => 

If  CMPTR— 3.. MUX-BUS-OK  s  TRUE 

then  MUX-COUNT  :=  -1  ; 
end  if  ; 
when  -50. .-1  *> 

If  CMPTR-3.MUX-BUS-0X  =  TRUE 
tnen  mux-COUNT  :=  mux-COUNT  -  l  ; 
if  MUX-COUNT  <=  -50 
then  MUX-HEAL  MuX.HLAL  ♦  1  i 
if  MUX-HFAL  >  6 
then  MUX-COUNT  :  =  4  : 
else  MUX-CHK  ;s  TRUE  ; 

mux-Count  :=  o  ; 
end  if  ; 
end  if  i 

else  mux-count  :=  -1  ; 
end  if  ; 
when  4  => 

CPU-CHK  :=  FALSE  l 
end  case  ; 


--  Failed 


mux  Bus  Chectcs  -- 
--  Normal 


--  Faulted 


--  Healina 


Failed 
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case  ACTR.COUNT  Is  --  Actuator  Chec<s 

when  0..2  =>  ““  Normal 

It  ACTR.COUNT  s  f) 

then  if  servo. 3 .actuatok.on  s  false 

then  ACTR.COUNT  :  =  1  ,• 
end  if  ; 

else  if  SERV0_3.ACTUAT0R.0N  =  FALSE 

then  ACTR.COUNT  ;s  ACTR.COUNT  ♦  1  t 
if  ACTR.COUNT  >=  3 
tnen  ACTR-CHK  :=  FALSE  } 
end  it  ; 

else  ACTR.COUNT  :=  0  ; 
end  if  ; 
end  If  ; 

wnen  3  - >  mm  Faulted 

it  servq.j. actuator-on  =  true 

then  ACTR.COUNT  :*  -t  ; 
end  if  ; 

when  -50. .-1  =>  •-  Healina 

it  SERVO. 3. ACTUATOR.ON  =  TRUE 

then  ACTR.COUNT  :s  ACTP-CUUNT  -  }  ? 

if  ACTR.COUNT  <=  -50 
then  ACTR.HEAL  :  =  ACTR.HEAL  ♦  1  i 
It  ACTP-HEAL  >  2 
then  ACTR.COUNT  :*  4  ; 
else  ACTR-CHK  :=  TRUF  ; 

ACTR-CQUNT  js  0  ; 
end  it  ; 
end  if  ; 

else  ACTR.COUNT  :s  -1  ; 
end  if  ; 

when  4  =>  --  Failed 

ACTR-CHK  :=  false  ; 
end  case  ; 
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case  LVOT.COUNT  1* 

■  nen  0.,3  a> 

It  LVOT. COUNT  *  0 

tnen  If  SERV0.3.I.VDT.VALID  a  F ALSt 

then  Lvot.count  :>  1  i 
•nd  If  i 

else  If  SEBVO.3. LVPT.VALIO  a  FALSE 

tnen  lvot.count  i»  lvdi.count  ♦  1 

It  LVOT.COUNT  >a  4 
tnen  LVOT.CHK  l»  FALSE  ; 
end  It  i 

else  LVOT.COUNT  l>  0  I 
end  It  l 
end  It  I 
■nen  4  *> 

If  SFRVU.3.LVUT.VAL10  «  THUt 
tnen  LVDT.CQUNT  la  -1  ; 
end  It  j 
■nen  -50..-1  ■> 

It  SFHVO.J.LVDT.VALIO  a  TRUE 
tnen  lvdt.cqijnt  :a  lvot.count  -  l  r 
If  LVDT.COUNT  <*  -SO 
tnen  LVOT.HFAL  I  a  LVDT_HEAL  ♦  1  ; 
It  LVOT.HEAL  >  2 
tnen  LVOT.COUNT  is  b  ; 
else  LVQT.CKK  la  TRUF  I 
LVOT.COUNT  tm  0  / 
end  It  ) 
end  If  i 

else  LVOT. COUNT  !■  -I  J 
end  If  » 

■nen  b  »> 

LVPT.CHK  I*  FALSE  I 
end  case  i 


LVDT  Sensor  Cnecks 

--  Norsal 


Faulted 


--  Heallnq 


Fal lea 


CnNL.STATU3.VJ  }■  CPU.CHK 


end 

end 


TOP.CHK 

LVDI.CHS 


end  "Ut.CHK  ana  ACTh.CHn 
end  servj_3.po«er.av*:l  ; 


••  No  N-verslon  vote  Taken  Because  Status  is  Unique  to  eacn  tnennei 
end  ASSESS. CHANNEL. V  3  I 
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Ada  Package  CHNL_3_ASSESSMEnt.V3 


package  CHNL-3-ASSESSMENT  is 


CPU.COUNT 

• 

INTEGER 

range  -10. .2 

s 

0  ? 

IOP.CQUNT 

e 

• 

tntegep 

range  -10. ,2 

s 

0  ; 

MUX.COUNT 

• 

• 

INTEGER 

range  -50.  ,4 

s 

0  ; 

ACTR.COUNT 

• 

• 

INTEGER 

range  -50, .4 

s 

0  : 

LvDT-COUNT 

e 

• 

INTEGER 

range  -50. .5 

= 

0  : 

CPU.CHK,  IOP.CHK 

9 

MUX.CHK, 

ACTP-CHK,  LVUT.CriK 

• 

• 

PQDLEAN1 

: =  TRUE  ; 

CPU. HEAL 

• 

• 

INTEGER 

range  0..5 

= 

0  ; 

IQP.HEAL 

e 

e 

INTEGER 

range  0..5 

= 

0  ; 

MUX. HEAL 

e 

• 

INTEGER 

range  0..6 

= 

0  ; 

actr.heal 

• 

• 

INTEGER 

range  0..2 

s 

0  ; 

LvOT.HEAL 

• 

• 

INTEGEP 

range  0..2 

= 

0  ; 

end  CHNL-3-ASSESSMENT  ; 

package  body  CHNL-3-ASSESSMENT  is 

beain 
null  ; 

end  CHN'L-3-ASSESSMENT  j 


Figure  A- 3  Package  CHNL  3  ASSESSMENT 
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AV.V.  v- 1 


A.. Ax AiJU  A ."-A  •  »  *ji  V  V  V  >  V  *A 


Ada  Procedure  GIVE-STATUS-V3 


with  voting-planes  ;  use  voting. planes  ; 

seDarateCDFCS -LOGIC) 

Procedure  GIVE-STATUS-V 3  is 

beqin 

ANNUN_V3.FLY.QLTY  :=  FLY— UUAL— V  3  ; 
case  MODE.ENG.V3. AUTOPILOT  is 
wnen  OFF  => 


ANNUN.V3.AFCS.STATUS  :=  AFCS. 

ANNUN_V3.AL_PRnG.DTSP  !=  (1..5 

A NNUN.V 3. AUTOPILOT. MODE  :=  OFF  i 
when  AUTOLAND  => 

if  AL.PHASE.V3  =  AL'TOLA  ND.I  NOP 


=  AFCS.DSIENGAOED  } 
=  (1..5  =>  FALSE)  ; 
=  OFF  ; 


then  ANnUN.VI. AFCS.STATUS  :=  AUTOPILOT. ENGAGED 

ANNUN.V3. AuTOPILOT.MODE  t=  BASIC  t 

ANnUN_V3.AL_PRGG.DISP  :=  autolahd. engaged.  ; 

else  ANNUN.V3. AFCS.STATUS  :=  AUTOPILOT-ENGAGED 

ANNUN.V3. AUTOPILOT-MODE  :=  AUTOLAND  ; 

case  AL-PHASE.V3  is 

when  AUTOLAND. INOP  => 

ANNUN_V3.AL-PR0G.DISP  :=  Ci..5  =  >  FALSE) 
when  AUTOLAND- ARMED  s> 

ANNUN-V3. AL-PROG-DISP  :=  (1  =>  TRUE, 

2 . . 5  =>  FALSE ) 

when  GLIDESLUPE-TR AOK  => 

ANNUN-V3.AL— PR0G-DISPC2)  :=  TRUE  ; 
when  DECISION-ALTITUDE  => 

ANNUN-V3. AL-PR0G-DISPC3)  :=  TRUE  : 
when  ALERT-ALTITUDE  => 

ANNUN.V3. AL-PR0G-DISPC4)  :=  TRUE  : 
when  FLARE  => 

ANnUiN— V3.  AL— PROG— D  ISP  ( 5 )  :=  TRUE  : 
end  case  ; 
end  if  ; 
wnen  others  => 


ANNUN.V3. AFCS.STATUS 
ANNUN.V3. AUTOPILOT.MODE 
A NNUN.V3. AL-PROG-DISP 
end  case  ; 

chnl-3-XChk-num  :=  2; 
XCHK-SYNCH-3  ; 

end  GIVE-STATUS. V3  ; 


=  AUTOPILOT-ENGAGFD  ; 

=  M0DF-ENG-V3. AUTOPILOT  ; 
=  (1  ..5  =>  FALSE  )  ; 


Figure  A-4  Procedure  GIVE_STATUS_V3 


■L?  *->  .JVV  Aa  ■li-M  a  LV  kVk  ivL\\vV\  -  A‘»V u%l*uV  -*»  oV  -N.V 


Aaa  Proceaure  “ANAGt._Al._St.nsnKS_v  $ 


»itn  CHnI._3_al_vCtEK  ;  use  CHNf._3_AL.V01'EH  ; 
*ltn  DFCS.LUGlC  ;  use  CFCS.LOGIG,  t 

kirn  VC  I'l  nG.PLAnFs  ;  use  vOTING.PLAnFS  ; 

separaieCofCS.RtSGiiKGES) 
proceaure  >«ANAGE_AL_S£Nsan  s_V3  is 


GS.FLAGs.in,  CS.COMk.IN, 
»A-COmP-OLT 

NA.FLAG3.1N ,  NA.COMP.IN, 

GS.SICNALS,  RA.StGNALS 
NA.iI(,NAL5 

gs.mfd,  na.hfo,  ra.mfo 


GS.rONF.oii  r,  kA. FLAGS. I N  ,  HA_CuMk-lN  , 

!  BUDL. VECTOR C 1 . .4)  ) 

nA_ConF.OI)T 

I  BOOL. VECTOR  1 1  •  ,  J  )  .* 

:  real-vector (i ..4)  ; 

:  PEAL- VECTOR  Cl. .31  t 
:  FLOAT  l 


neai  n 

for  Index  In  1..4 
loop 

GS.FLAGS.IN  C INDEX )  :=  A  L.FLACS  .  C.S.HE  AM.  v  A  L  C 1  NDFa  1  J 

P  A.f LaGs.IN  C INDEX )  :=  AL_ FLAGS . k  AO. A LI. V  AL( INDEX )  ! 
end  1  cop  1 
tor  index  i n  1 . .  3 
loop 

NA. FLAGS. IN ( I NPEX  J  ;s  AL.F LAGS . N.ACCEL.V A L ( XNLF X )  t 
end  loop  ; 

rHK_AL.Fl  AGs.INlGs.f  LACS.ill,  1,  4)  ;  --  Gnec*  Sensor 

CrtK.AL_FLAGS.XNi  NA_FLAGS_Ih  ,  2,  3)  >  --  Flay  input. 

CnK_AL.Fl AGS.iNCPA_FLAGs.XN,  3,  4)  I  *-  Validities 


'or  T«r EX  In  l,,4 

loop 

OS.SlGNALSlIwDtX)  :=  FLOATCGS.UFAN.DEVCIhDEX) 1  l 
PA. SIGNALS! INDEX)  ;s  FLO AT C R AD. ALT ITUDE C I NDFX ) )  } 
ena  loop  i 

tor  InDlX  in  1..3 
looo 

NA.SIGNALSC INUEX)  :=  FLOATCNOHM.ACCt'  ClNDtXn  : 
e~o  loop  : 

VOTE_AL_SENSnpSC  CS.S  TGNALS ,  1,  4,  GS.mEO)  ,* 

al_mfl_v3.gs.opv  :=  blam.OEV.sIonalcgs.med)  ; 

VoTfc_Al._S£NSDkSCNA_SIGNAlS,  2,  J,  NA.MFO  1  J 

AL.MFO.VS.N.ACCtL  1=  AC CEL.S I  ON AL C N A.rtFu )  1 

V0TE.aL_5c.NsDHS(RA_ST0NALS,  3,  4,  RA.mFO)  I 

al_mEu-V3. rap. alt  :=  rao.ali.stonalcpa.med)  ; 


select 
*ea 1 dn 
sensor 
olgrals 
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It  mY-Tupn  tnen 

'•MK.FaI,LT_I  oGIC  ( GS-b  ToNALS  ,  CS„NFU,  1,  4,  GS-COMP..OUT  )  ; 

CnK_FAUl.T_LUC:iClNA_SI(,NALS,  NA_KEO,  2,  3.  NA«C0hP_0uT )  ; 
fnK.FAUuT.LufUCCWA-irUNALi,  RA.MEO,  1,  4,  RA_CO«P_nuT)  ; 
Pt.IUhF  ts  FALSE  ; 

«1S«  AY.TUPN  :a  TRUE  ; 

end  l t  : 


•-  Compare 
••  Inputs  s 
--  Cnee* 


Comparators 


for  IwPEX  In  1..4 
loop 

Al-CHmP.V J.LS_BEAM_VAL( INDEX)  ! 

AL.CnhP_VJ.N_ArCFL_VAL(i»i»FX)  t 
er.d  loop  ; 

for  InDc.X  in  1..3 
loop 

AL_COMP_V J.kaD_AL1_VAL( inlcxi  : 
end  loop  » 

ChVL.j_xrrtK,NUP  :=  3  ; 

XCHK..SYNCH-3  ; 

end  pa> ace_al.senspks_V3  ; 


LS.CUPP.UUTt INDFAl  ( 
HA.CUMp.OUTt 1M1FX)  t 


=  KA_CU»P.UUTU*dFA)  } 


Call  tor  N-verSion  vote 
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Knl 


i.VeV.-W..V-A 


Package  CHNL.J.AL.VoTER 


package  CHNL.J-AL.VOTER  It 


AL-COMP.COUNT  s 

array 

u , 

.1,  1..4)  ot  INTECEP 

ranoe  0..b 

i* 

(l. 

. J  =  >  f 1..4  *>  0))  • 

AL-FLAG.COUNT  1 

array 

( l . 

. 3,  t . • 4 )  ot  INTEGER 

ranoe  -5,.s 

t  3 

( t . 

.j  =>  a. .4  =>  on  ; 

AL.FI.AG.TN  1 

ar  ray 

(i . 

.1.  1..4)  ot  bOO'SAN 

:* 

(other*  *>  totnert  *>  TRUE))  » 

AL-COMP.OUT  : 

array 

( 1 . 

.3,  1..4)  Ot  bCOLE AN 

1  3 

(other*  s>  (otners  *>  TRUE))  t 

MJ.TURN 

l 

bOULEAN  1 

NUM.SLNbORS 

l 

INTFCFR  ranoe  1..4 

!=  4  ) 

NUM. votes 

t 

INTEGER  ranoe  0..4 

ts  0  ; 

SET.NUM 

l 

INTEGER  ranoe  1..3 

i=  t  J 

type  bnoL.VECTOR  js  array  (Intfgeh  ranoe  <>)  ot  poolean  » 
type  REAL.VECTCR  la  array  ( INTEGER  ranoe  <>)  ot  r ldat  > 

procedure  OhE.AL.FL AGS-1N ( AL.KL AG  :  In  BOOL.veCTHR  ;  SET-NUn, 

NUM.StNar.nS  i  In  INTFCER)  I 

procedure  V0TE_AL.3ENS0K3(AL_SrN5DRS  :  in  REAL_VECTUR  > 
SET.nux,  NUN.SEN50RS  i  In  integer  I 
AL_SENSQR.mEO  S  out  FLOAT)  J 
procedure  CHK.rAULT_LQCIC( AL.SFN50RS :  In  REAL. VECTOR  ; 

AL— SENSOR. NED  I  In  FLOAT  !  SET-NUM,  NUM.SENSORS  : 

In  INTEGER  J  AL.CUMR.V  AL  l  out  BOOL.VECTOR)  I 


end  CHNL-3-AL.V0TER  ) 
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oecitsge  body  CHNL.l.AL.VOTEH  If 


oroceoure  cmk.al.flags.in! al.flac  :  in  bOOL-Vetton  ;  set_nun, 

NU“_SENSOH5  :  In  INTEGER 1  1* 

Benin 

for  index  in  l . . nun.sensdrs 

loop 


C4SC  AL.rLAC.CnuMKSET.NUN,  INDEX)  IS 
■  nen  0  *> 

If  AL.FLAGt 
cncn  AL.FLAC. 
end  if  i 

■nen  I..S  ■> 

If 


INDEX)  «  FALSE 
COUNT (SET. MUM,  INDEX) 


AL_FLAC( 

then  AL.FLAC. 
AL.FLAC. 
It  AL 
tnen  AL. 

AL. 
end  It  > 
else  AL.FLAC. 
end  If  ) 
-S..-1  ■> 

If  AL-FLAGC 
men  AL.FLAC. 
AL.FLAC. 
It  AL. 
tnen  AL. 

AL. 
end  It  j 
else  AL.FLAC. 
end  If  ; 


INDEX)  *  FALSE 
COUNT(SET_NU“,  INDEX)  t« 
rOUNTlSET.NUN,  INDEX)  ♦  1} 
FLAG.CDUNTtSFT.NUN,  INDEX) 
ELAC_IN(StT_NUN,  INDEX) 
FLAG-COUNT tSET.NUN,  INDEX) 

COUNT! 5ET.NUN ,  INOEX) 


1  » 


INDEX)  ■  TRUE 
CUUNTtSET.NU",  INDEX) 

COUNT ( SET .NUN ,  INDEX) 
rLAC.COUNTtSET.NUN,  INDEX) 
FLAG.1N(SET.NU»,  INDEX) 
FLAG. COUNT  tSET.NUN ,  INDEX) 

COUNT  1  SET. NUH,  INDEX) 


--  Nor*el 


--  Eeuited 


>*  s 


rALSE 

•1  ) 


Heeilno 


<«  -5 

• ■  tkue  j 

:  *  n  i 
:  *  -  l  i 


end 

end  Che. 


end  C4se  ; 
loop  l 
AL.FLAGS.1N 
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Procedure  VOTt.AL.SENsnNS  l AL-SFNSUPS  S  in  Rt»L_VFCTuB  I  StT.MUM, 

NUN.SFNSOBS  S  in  TNTEGEB  »  AL.SFNSOB_»ED  :  Out  FLOAT )  1$ 

SET-RANKING  :  nrriv  (1..A)  of  I NTtGtB  r<rg«  0..4  :*  (0,  0,  0,  0J  i 

v  t  array  of  float  u  to.o,  o.o,  o.o,  o.o)  > 

TFNP  !  FLOAT  t»  0.0  l 

Ota  in 

NUN.V01FS  sa  NUN.SFNSOBS  t 
for  INDEX  In  1 .  .NUN.SFNSOBS 
looe 

if  AL-CnNP.nuTlStT.NUN,  INDFX)  x  FALSE 
than  NUN.VUTES  S»  NUN.VOTES  -  1  I 

tl le  S£T_pankTi»G(  index)  :«  TNntx  » 

•no  if  : 

•no  loop  > 

tor  JXDFX  in  1 . .NUN, votes 
loop 

tor  CHNl.NUN  in  INDEX. .4 
loop 

if  CHNL-NUN  «  SFT.HANKINGCCKNL.NUN) 
trim  V  (  INDEX  1  |i  AL.SENsnkSlCNNL.NUN)  t 
exit  ; 
end  1 f  ; 
end  loop  ; 
end  loop  > 
case  nun, VOTES  is 

•  nen  0  *> 

null  > 

•  hen  1  *> 

AL.SENSON.NFO  :*  V(l)  ( 

■nen  2  *> 

if  V(l)  < *  V ( 2 ) 

tnen  AL.SENSQP.»en  s*  V(l)  » 
else  al-SEnSOP-“EO  sa  v { 2 1  i 
end  if  t 
•nen  3  «> 

If  ( v ( 2 )  <a  V { l >  and  V(l)  <a  V(J))  or 

( v c  3  j  <•  w c  t  J  and  v ( l )  <a  van 

tnen  AL.SFNSOP.NED  i*  V(l)  } 
elslt  (V(l)  <•  V ( 2  3  and  V(2)  <a  v  t  3  J )  or 

( V  (  3 )  <»  V  C  2  3  and  V(2>  <a  VCD) 

tnen  AL.SFNSOP.NED  sa  V 1 2  J  t 
else  AL.SENSOP,»tn  sa  V  C  3 3  f 
end  if  J 
•nen  4  a> 

tor  t  In  1 .  .NUN.VUTES-1 
looo 

for  J  in  1*1.. nun. votes 
loop 

if  V(T)  >*  VIJ) 
tnen  tenp  :a  vd>  ; 

V  c  T  J  ;  a  V  <  J  )  ; 

V  ( ,1 )  SX  TENP  ; 

end  It  i 
end  loop  t 
end  loop  s 

AL. SENSOR. NFO  sa  V  c  2  3  ! 
end  case  s 

end  VUTE.AL.. SENSORS  I 
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procedure  CnK.F  AULT-LOOICl  AL-SENSOBS  I  In  REAL-VEOTON  ; 

4L-5ENS0B-REP  t  In  FLOAT  ;  SET.NUR,  NuR-SENsOHS  I 
In  INTrCER  I  AL-CU»P.VAL  1  out  BOOL-VECTOr )  It 

arPL-LInIT  i  Array  U..3)  at  FLOAT 

II  (1  «>  0.050,  2  *>  0.025)  t 

RAX-CT  i  constant  array  (1..3)  of  INTEGER  s=  (5,  4,  4)  ; 

had  in 

for  Index  In  l . .nuR-SEnsObs 
loop 

If  set-nun  *  3 

tnen  ARPL_L1«IT( 3)  :■  0.02*  AL-SENSOR-NEP  I 
end  It  | 

cata  AL-CORP-CPUNT(SET_NUR,  INDEX)  IS 

•nan  0  *»  *•  Noraal 

If  ao*(AL-SENSOR_R£D  -  AL. SENSORS  t  INDEX  )  )  >» 

ARPL— LI R  TT(SFT-NUR) 

than  AL-CORP.COUNTISET.NU",  INDEX)  I*  1  ) 
and  If  t 

•nan  1..5  «>  - *  Fauitan 

If  aos  { AL-SFNSQB-NtD  -  AL-SENSQRS t INDEX ) )  >■ 

ARPL— LTRTT1 SET— NUR ) 
tnan  AL-CORP-COMNT ( SET-NU" ,  INOFX)  IS 

AL— CORP.COUnT (SET. NOR,  INDEX)  ♦  1  t 

It  AL— CO- P— COUNT fSET— NUN,  INDEX)  >«  N* X.CT C SEI-NUR ) 

tnan  AL.CQRP.OUT (SET. NUN,  INDEX)  :■  FALSE  » 

AL-CQRp— COUNT ( SET-NUN ,  INDEX)  |«  5  ) 
and  tt  1 

alsa  AL_CORP-CQl)NT(SET.NU»,  INDEX)  I*  0  ;  --  Recovering 

and  If  » 

•nen  6  *>  --  Faliaa 

null  j 
end  case  ; 

AL-CORP-VALlINOEX)  !»  AL-CORP-OUTtSET-NU",  INDEX)  or 
AL-FLAO.INCSET-NUR,  INDEX)  J 

end  loop  ; 

and  CMF-FAULT.LQGIC  J 
and  CMNL-3-AL. VOTER  I 
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V 

ry 


»mr-Mr*.irwtrwirww-Nir««~Rvev.nr*  VW  wwwm  'iwiwim'nni 


Ada  Proeeaure  OAf.C-A’iiOLAwD-Vj 


■  ICn  A! -PESul'ROtS 

■  It  n  ufCS-LcGlC 
»ltr.  uECS-RESLUKCES 
»itn  vottnG-PL»nes 


I  111*  AL-hESOUPCF  5  ; 
i  use  DFCs-Logic  ; 
l  use  nt CS-REsOURCEs 
l  use  vuTING-pLANES  : 


seoarareC  control— LAas ) 
Drocedire  CaLC-AUtolarD-v j  is 


case  NOLE-ENG-VA.AUTOLANn  is 
»n»n  CAT-1  |  c'AT_2  I  CAT-JA  *> 

If  INITIALIZE  «  FALSE 

men  AL.PHASE.f 3  :*  AtiiOLANO-InCH  ; 

AU-SENS-MEDIANd)  :«  FLUA T C AL-REC-V J . uS-PEV )  ; 

AL-SE:jS.“ED1AN<  2)  s*  ILUAICAL-NED-VI.n-ACCEl)  I 

AL-SEn5.»ED1AN(  J)  :*  H.UAICAL-»tD_VJ.hAU-ALn  ! 

,  AL-SEnS-REPI ANfal  :=  FLUATC1L_“EP.V3.P-AATE,  1 

CALC-AL-STFERINuC  AL-SENS-REOI AN ,  nnor_F  NG-V  i  .  AtITOL  A  r.P  , 
At.— PHASE  — V  j  ,  AL-STEFhINC-ChD)  i 
TNITTAI 1ZE  i*  TRUE  ; 
ecu  if  } 

RAU-ALT  :*  ELOATC'AL— MEu— V3#HAP— ALT)  ; 

CRtCK— SUB-ROC' EC  RUDE— ENO-V  I.AUTCjLaND,  RAD-ALT,  AL-Pn AoE_V  i  )  j 
At-St"S-AEulAN( 1)  J*  ELOaT CAL-NED— V3.CS-OF2)  r 
AL-SeN3-*EuIANC2)  :«  FLOAT  (  AL-REu. 2  3  .  N-ACPEL  )  ; 
AL-.t£NS-HEOlAN(3)  S*  FLOAT  CAL-HF3-V3  . R  AD-ALT )  ( 

AL— SENS— NFU I AN ( 4 )  :*  FLOAT C IL-NEO-2 3 . P-RATE )  » 

CALC— AU— STEFnliiCtC  AL— SENS— PEP  I  AN  »  NUDE-ENu-2  3  .  AUTULANU  , 

AL— PH  ASE-V  3  ,  AL-5TEC.R  1 NG— CD  )  ? 
AllTOLANO_CMO-V3  :«  P ITCH— CORN AnP  C  *L— STEER  I  nG-ChD )  ; 

■nen  Jrt  »> 

it  initialize  =  tpue 

men  AL-PMASt-23  :*  AUTOlANP-INOP  ; 

AL-SEnS-REDIANCi)  :s  FLOATf AL-“EP_VJ,uS-ntV)  ; 

AL— SEi«S— Rt.Pl  AN  (  2  )  :s  FLuAlCAl.-REn-Vj.N-ACCFL)  ! 

Au— SENS-REO I  A  N  C  3  }  !s  FLOAT  t  AL-NlD.V  3  .  n  AO-A  t,  D  » 
AL-SENS_«EDIANC4)  :s  FLUATCIL— mED-V3.P— RATEj  ; 

CALC-AL.5  IFERIHUt  AL— SENS— REUIAN  ,  HODF._EnG_V  j  .  AU  IOLAnP  , 
AL— PHASE-V3,  AL-STEEHInG-CRPJ ; 

initialize  :=  false  i 

eno  if  ; 
enc  ease- ; 

ChfU-J-AChE-HOR  : =  4  ; 

XO'A-STNCH-J  ; 
enH  CAt  C-AlimLANC-V  j  ; 
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I 


Package  »  E  SOUP  G  F  S 


«itn  oFCS.tucic  t  use  ofcs-lfigic  ; 

■  Itn  OFCS.PESOURCES  ;  use  DFCS-XFSOUBCFi  ; 
oacsage  »L_ME5nuBCFS  IS 

-•  Signal  snaplng  Filter  n0ettlcients 


Filter  1  s  GUdesiope  Deviation  Lo«-Pass 


fiSI_F,  GSI_F"1 
GSO.FXl 


:  constant  i*  1.0/e.u  i 


i  constant 


J.O/4.0  ; 


■-  Filter  2  i  Nornal  Acceleration  Mlgn-Pass 


NZt.K 

NZ1-KN1 

NZO.KMl 


i  constant 


90„.u/gOi.o 


5  constant  :«  -900. 0/901 , u  \ 
l  constant  l»  8*9.0/901,0  < 


Filter  1  :  Altitude  Acceleration  Loa-Pass 


Hjni.d,  H201_A»1 

tf200_K»«l 


l  constant 
t  constant 


1.0/22.0  | 

9.0/11.0  ; 


Filter  4  s  Radio  Altitude  Hion-pass 


Hl_K 

Hl„K»l 

HO_K“l 


:  constant  S*  20,0/11,0  ; 


i  constant  ;* 
:  constant  :* 


■20.0/11.0  ; 
9.0/11.0  ( 


Filter  S  i  Gl Ides  lop*  Comeand  Fader 


ACS1.K,  AGS l-A" 1 
AGSU.KF 1 


t  constant 


l . 0/ 6 l . u  ; 


i  constant  !*  ue.o/si.o  ; 


Filter  e  i  Coeeand  Kete  t.l*lt*r 


pate. tie  I T 


:  constant 


--  Filter  ^  i  Plten  pate  Error  Fader 


PRFl.A,  PMEI_K*l 
PRFO.sei 


t  constant 
s  constant 


1.0/11.0  j 

29.0/11.0  ; 


..  Filter  8  i  Altitude  Acceleration  integrator 


H2DAI_F.  M2DAI_n»l 
H2DAO_F«l 


S  constant  :*  1.0/20.0  ( 
:  constant  :*  1.0  » 
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Ga 1 n  scneauies 


•  •  Gltaeslooe  Oesent  Hat  Ion  Gain  (60  to  1000  FT . ) 

KGS  i  constant  :«  1.0/9400.0  ; 

--  Flare  Command  Gain  1-20  to  60  FT.) 

kfl  s  constant  :•  -S.O/eO.O  ! 


Control  Lae  Varlaolat 

OS.EPH,  GS.tRR.LP,  GS.FRP.65. 

OEL.HZ,  H.2UOT,  H.ZOOT.AUC,  H.7DOT.LP, 

HrA,  RRa.hP .  H.OOT . 

M.DOT.GS,  H.POT.REF,  H.UOT.AOS,  H.DOT.CriO 1  , 

H_DUT_CN02 .  H.DUT.EHR . 

Pr_C"D,  PP.CmO.L  t  N .  PR. ERR  :  FLOAT  I 


--  Filter  eenorv  varlaoles 


0L0.G5.LBH .  0Ln.G5.EBR.LP*  OLO.DFL.MZ,  0LD.H.200T, 
OlD.H_2DOT.LP,  0LD_H.20OT.AOG,  OLD.ri_DOT.KFF ,  OLD.HhA, 
OlO-HHA.HP,  OL0_H_nOT_ACS ,  OLD. PR. ERR , 

OLO.H_DUT.CeO 1  I  FLOAT  > 


Progress  trio  Points 


G 1 1 aes looe/ Auto  land 

alT.blF.i 

AlT.BEF.2 

ALT.BEF.3 

AlT.REF_4 


j  consrent  :»  200.0  t 

I  constant  ; e  160.0  ; 

I  constant  i*  100. 0  t 

i  constant  i*  60. o  t 


tyoe  sensor-vector  Is  array  U..4)  ot  float  ; 
AL— SENS.NE01AN  I  SENSOR-VECTOR  t 


AL.STtERINC.CNO,  PITCH. R*TE,  RAD.ALT  1  FLOAT  I 


initialize  i  boolean  :*  false  > 

ornceaure  CALC.AL.STEEPINGfAL.SENSOK.eFDS  :  In  SF ns JR.V tCl Cri  ; 
SLL.A  L.NODF  S  In  AL.CATECOBI  I  NODE.ST  »  T'Ja  : 

In  AL.PROGPESS  ;  PITCri.AL.CriD  1  out  FLOAT)  ; 

oroceaure  ChEC*.SUP.*ont(5FL.AL.NuDt  :  in  al.CATElOhy  » 

RAO. ALT  s  In  FLOAT  ;  eODE.STATUS  : 
tn  out  AL. PROGRESS)  ; 


ornceaure 

oroceaure 

oroceaure 

ornceaure 

oroceaure 


I N I T I  AL  1  Zb.F  I  LTtPS  ,* 
CALC"L»TF.GLIOF5LOPE  ; 
CALCULATE.FLAHF  t 
FADtB.LieiTtB  » 
RESET-FILTERS  » 


end  AL. RESOURCES  ; 
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oaCKaqe  no<iy  AL. RESOURCES  Is 


k 
\ 
s 


orccfdur'  C  ALC-AL.STEERINGt  AL.SENSOK.HFDS  :  In  SEnSuR.VEC fOn  i 

SEL.AL-HOOF  I  In  At.CATEGOPT  ;  HODF.STATUS  i  in  AL-PRUGkESS 
PITCH. AL_C«D  ;  out  FLOAT)  IS 


beoin 


=  AL_SENSOH_HEDS(t )  J 

*  AL_SENSOH_NFDS(2)  l 
s  AL.SENSOR.HFDStl)  i 

*  AL.SENSOR.HEOSH)  i 


GS.FRP 
OCL_*sZ 
HRA 

P I TCb.H  ATF 
rise  srL-Ar._«ont  is 
•  n»n  CAT. 2  I  CAT.ja  i> 

It  *OuF. STATUS  «  AUTOLAnO.INOP 
then  INITIALIZE. F1LTFHS  ; 
nisi  t  NUD t.ST  ATUS  «  FLARE 
tnen  CALrULATE— FLARE  I 
else  CALCULATE.GLIOESLOPE  » 
end  1 1  > 

»nen  CAT.l  s> 

It  MOCF.STAT'li  i  AilTOLARn.INnp 
men  I N iti alIZF.FI LTFHS  j 
RlSlf  "ODE-STATUS  *  GLIOESI.QPE.TBACa 
men  CALCLI.ATt.GI.intSLnPF  I 
eislt  "ODE-STATUS  »  DECISION. ALTITUDE 
Mien  FAUFR.LIMtTEK  I 
end  If  l 
■  ne>n  OFF  *> 

RfcSLT.riLTFHS  ; 
end  cm  I 

PITCH. AL-C*D  :«  PR. ERR  J 
end  CaLC-AL.STEERING  ; 
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»  ,  *  ,  t*. 


oroceaure  CnFCK-SUB-MUDECsFL-AL-MODE  :  in  AL-CATECOHY  ;  rsD-ALT  : 

In  FLOAT  i  MODE-STATUS  :  in  out  AL-PROGRESS)  is 

neain 

CAS*  SEL.AL.MO0t  is 
•  nen  C»T_2  I  CAT.JA  *> 

cas*  mode-status  is 

•  hen  AUTULAND.INOP  •  > 

MOOE.STATUS  :  =  A'lTOLAhO-ARMEO  » 

•  hen  AUTOLAND. ARMFD  *> 

MODE-STATUS  :*  GLintSLOKF.TRACK  » 

•hen  clideslope.track  => 

It  SEL_AL._mqde  =  CAT.2  end  then  RAD.ALT  <=  ALI.REK.2 
tnen  MODE-STATUS  t=  DECISION-ALTITUDE  ; 
elilf  RAD.ALT  es  ALT. REE. 1 

then  MODE— STATUS  :=  ALERT. ALTITUDE  ; 
end  It  ; 

•nen  DECISION-ALTITUDE  I  ALFRT. ALTITUDE  s> 

It  RAD.ALT  <«  ALT.REE.4 
tnen  MOOE.STATUS  :  =  FLARE  » 
end  It  ; 

•hen  ELArE  s> 
null  » 
end  case  » 

•nen  CAT.i  s> 

case  mode-status  is 

•hen  AUT0LAND.1NQP  «> 

MOOE.STATUS  :»  CM DESLOPE. TRACK  I 
•hen  GLIDESLOPE.TRACK  x> 

If  RAD.ALT  <*  ALT.PtE.A 

tnen  MODE-STATUS  S«  DECISION-ALTITUDE  I 

end  If  ; 

•nen  others  *> 
null  » 
end  case  i 
•nen  OFF  *> 
null  i 
end  case  ; 

end  ChFCK_SUB_«00E  J 
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Procedure  InTTIAUZE.FILTERS  Is 
begin 

OLD.DFL.NZ  :=  DFL.NZ  1 
H-20UT  S*  0.0  } 

ULD_H_2nuT  :*  0.0  ; 

OLD.hR A  :=  nRA  ; 

HRA.HP  : s  0.0  J 

ULD.MRA.HP  :=  0.0  J 
end  iNITIAllZfc.FILTERS  ; 

Procedure  CALCULATF.GLIOFSLOPE  Is 
benln 

GS-EBR-LP  :  =  GSO_RMi»lLL_CS_EKR_LP  ♦ 

CSI-K“1  «OLD_GS_ERR  ♦  GSI_K»GS_£RR  ; 

OS-ERK-DS  :=  0.1»LS_EHR_LP  J 

It  HRA  «  mon.n 

tnen  gs.frr.os  :=  ( hka-aq. o ) *kos»gs_erk_ds  > 

end  1 t  ; 

H_?Df)T  :=  NZO_KMl«U[.D_M_2POT  ♦ 

(«ZI_A"l*OtU_DEL_NZ  ♦  MZI-K *DEL_NZ  ; 

olO-pel.sz  ;=  dfl.m?  : 

H_2uOT_LP  i  =  H20n_KAl»nLn_H_2UOT_LP  ♦ 

H20I-FH1 »PLD_H_2DOT  ♦  H2D t _K » H_2lPT  i 
nLP-H-2DOT  S=  H.2PC1T  ( 

old_h.2doi_lp  :=  h_2POt_lp.  ; 

HHA_HP  j=  HO.KMl »OLP-HRA_HP  ♦ 

Ht.KMt »nLO_HKA  ♦  HI_K»HRA  ; 

olo.hra  :s  hpa  i 

olo.mra.hp  :s  hra«hp  » 

H.OOT  t*  H.2DOT.LP  ♦  HRA.HP  I 

H_2DnT_AUG  S-  H.200T  *  G5.ERR.DS  I 

H.OOT.REF  J*  H2UAO_K«l •OLD.M.DQT.REF  * 

H2DAI-KMl»nLn_H_2D0T_AUG  ♦  H2D A l.n •H-2DUT.A uC J 
OLD.H.OOT.REF  JS  H.OOT.REF  I 

nLn,H.200T-AUG  :=  h_200T_aug  t 

H.OOT.AGS  :=  H.DOT.RFF  -  CS.FRR.DS  t 

h.dqt.cmoi  j*  h.dpt.ref  ; 

nLO.H_DQT.CMOl  !=  H_DnT_C“Dl  ! 

H.DUT.CH02  !*  -fl.O  ! 

H.OQT.ERR  !=  H.DOT.CXDI  ♦  H.D0T.CM02  -  H.DOT  ; 

pr.C"D  :*  o.5*H_oor_£RR  ; 

It  *OS ( PR.CM0.L1H  -  PR_C"D)  >=  RATE-LIMIT 
men  If  PR_C“0  >  0.0 

tnen  PK.CmD.LTM  S  =  PR-C^D-LIM  ♦  0.3  ; 
else  Pfi.CO.LIM  ;*  PR-CD-LTM  -  0.3  ; 
end  If  ; 

else  PR.CMO.LIM  t=  PR.CMD  I 
end  It  l 

PR.tRR  1=  PR.CMD. LIM  -  PITCH.RATE  J 

*nd  CALCULATF.GLIDESLOPE  > 


Finiirn wirwwiivwi  V IV nwiwwiwwiyung  HW«M KM B  ■  MRUPUW1  WUWUVM  W WyifBVlIVWWiaJWJlM.  ■VHT'J*  "J  rjrwwvrwv  Hy P.M ny ny  IVW 


Procedure  CALCULATE.E LAHE  Is 
begin 


H.2DOT 

!  = 

NZU.KM l*OLD.H.2DOT  ♦ 
NZI.KM1«0LD_DEL_NZ  ♦  NZI.KsDEL.NZ  i 

0LD.DtL.NZ 

:  s 

0EL.NZ  1 

H.2DOT.LP 

:  s 

H2DO.KM1SOLD_H.2DOT.LP  ♦ 
H2DI.KM1SOLD_H.2DOT  ♦  H2DI.KsH.2DOT 

OLD.H.2DOT 

:  = 

H.2D0T  | 

0L0.H_2D0T.LP 

;  s 

H.2DOT.LP  1 

hra.hp 

*  = 

H0.KM1 SOLD. HRA.HP  ♦ 

HT.KM1 SOLD.HRA  ♦  HI.KSHPA  ; 

old.hra 

:  s 

HRA  ; 

old.hra.hp 

:  s 

HRA.HP  1 

h.dqt 

u 

H.2D0T.LP  ♦  HRA.HP  1 

H.DUT.CMDi 

J  s 

PPEO.KMlsnLD_H_DOT.CMDl  ;  --  Eager 

OLD.H_DUT.CMDl 

l  S 

H.DOT.CMD 1  1 

H.DUT.CM02 

U 

(HRA  ♦  20 . 0 ) SKFL  1 

H. OUT. ERR 

:  = 

H.DOT.CMD 1  ♦  H.D0T.CMD2  -  H.DOT  ; 

PR.CMD 

•  s 

O.S«H_DOT_ERR  ; 

If  abs ( PR.CMD. 

LIM  -  PR.CMD)  >=  RATE.LIMIT 

tnen  If  Pr.C“D 

1  > 

0.0 

then  PH.CMD.LTM 
else  PH.Cmo.LIM 
end  If  l 

eue  pr.cmd.lim  :=  pr.Cmd  i 
end  If  ; 

PH.ERK 

end  Cai.CUlate.Flare  j 


=  PR_C*D_LIM  ♦  0.1 
*  PR.CMD.LIM  -  0.3 


PR.CMD.LIM  -  PITCH. RATE 


procedure  EADER.LIM1TER 
bed  In 

H.0QT.CMD1 
0LD.H_DOT.CMfU 
PR-CMO 


IS 


is  PRE0_KM1»0LD_H_D0T.CMD1  I 
I*  H.D0T.CMU1  I 
I*  H_OOT.CMD 1  I 

If  abs ( PR.CMD.LIM  -  PH.C-D)  >*  RATE.LI-IT 
tnen  if  PH.CMD  >  0.0 

men  PR.CMD.LIM  is  PR.CMD.LIM  ♦  0.3  > 

else  PR.CMD.LIM  !*  PR.CMD.LIM  -  0.3  { 

.  end  If  ; 

else  PR.CMD.LIM  ;s  PR.CMD  I 
end  If  ; 

PR.EBR  !=  PR.CMD.LIM  -  PITCH.R ATE  ; 

end  FADER-LIMITER  j 


oroceoure  REStT.FlLTERS 
begin 

0lD.OE.ERR 

0LD_0S.EBH.LP 

DLD.DtL.N2 

0LD.H.2D0T 

0LD.H_2D0T.LP 

OLO.H.2DOT— AUG 

DLD.H_DOT.PEF 

old.hra 

OL0.HRA.HP 
0LD.H_D0T.CMD 1 
OLD. PR. ERR 
end  RESET.P 1LTERS  I 


Is 


is  0 

!S  0 

is  0 
is  0 
is  0 
is  0 
is  0 
is  0 

is  0 

I  s  0 
is  0 


.0  » 
.0  J 
.0  ; 
.0  i 
.0  ; 
.0  ; 
.0  ; 
.0  I 
.0  ; 
.0  ; 
.0  » 


end  AL-RESOURCES  s 
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Ada  Procedure  A  anagf.  I  L_aENSGR3_V  3 


Witt)  CHM-.I-IL-VOTFn  ;  use  CHnL-  3- ! L_V OTFN  ; 

«itr,  uFCf-i.UGic  ;  use  dfcs— lug i c  : 

«itn  *otinG_plahf3  ;  use  vm inG-Planfs  ; 

seoarafeCDFCS-RESUlDiCES) 
procedure  «ANAC£_.n  .SENsiiW5_v.)  Is 


Cp-STK-Ef  AGs,  P_SlK_rLAuS,  AOA-fl.ACS, 
CP_3TK.Cr>P ,  P-STF-Cu*?,  AVG-ADA-CDMP 
P-PATt-FLAGS,  P-RATE-COmP 
TAS-FLAuS,  TAS-CCjHP 

CH-STK-SIGN'At.S,  P-S1N  .SIGNALS, 
avg.aga_.cig„als 
P-RATt-SIuNALa 
TaS- signals 


PuOL-*FCtLR  Cl  . .  4 ) 
KuOL-Vi  CTuh l 1 . . J ) 
BuOL-VFCTUR( 1 .  .2) 


PEAL_vFCTbR( 1 . .4)  ; 
REAL_VECTuR(l...»3  ; 
REAL-VFCTGRU  .  .2)  > 


Cp.aTK_.-iFD,  P-STK-NEP,  AVG.AOA-mFD, 

P.PATr—.lFU,  TAS-NED  •  FLOAT  t 

beo  1  n 


for  T  NDEX  In  1..4 
locp 

CP-aTK-KLAGaUNDEX) 
P-SIk.flagsctndex) 
aga. flags c index) 

if  INDEX  <=  1  tnen 
P-PATE— ELACSC  INDEX) 
It  INDEx  <=  2  men 
Tas.FLAGSC INDEX ) 
end  It  ; 
end  It  » 
end  loop  ; 

ChFCK-IL-FT  AOa (CP- SIX-FLAGS, 
CnKCF-IL-t  LmCSCP-oTK-ELACS, 
CnECK-lL-r LAGS (AO A-f LAGS. 
GhEC*— IL— EL AGSfP-PArE— FLAGS, 
CHFCF-Il-E LAGS CI*S-f  LAGS, 


--  Input  Flag  Type  Conversion 

:=  TL-ff. AGS. CP-STK.VALC  INDEX)  ,• 

:=  IL.EI.AGS.P-STK-VALC  INLF.A)  ; 

:=  IL.r Lags .lE-AOA-VALCInDLX)  and 
IL-FLACS.RT-AGA-VALCINDEX)  ; 

IL-fLAGS. P-hATE-V At (INDEX )  } 

;s  I L— FLAGS  .TAS-VAL(INdEX),’ 


••  Input  Validity  Flag  CDecxs 

l,  «3  ; 
l.  A )  ; 
i,  *)  ; 

4,  3)  1 

5,  2)  ; 


for  InPlX  In  1..4 
loop 

Cp— STK— SIGNALS( INuFX) 
P-S(K-S1Gi,ALS(  INDEX) 

A  VG-AUA-SIGNALSv INDEX) 

it  INDEX  <*  3  tnen 
P_  w  AT  t — a  ( GN  A  [.S  f  INDFA) 
if  index  <=  2  tnen 
TaS. SIGnAlS  l  INDEX  ) 
end  It  ; 
end  It  ; 

end  loop  ; 


--  sensor  Slanal  Type  Conversion 

FlOATICP-STICK— CMP( INDFa) )  ; 
ELDATCP-STICX-CnP  l  iNDtX  )  1  ,• 

(  I.LAT(LEFT_AUA(  INDEX)  1  ♦ 
FLOAT(RIGHT-AGA(INOtX) ) )/2.0  ; 

FLOAT  t  P-P  ATE— GYRO (INDEX) 1  i 

FLOATlTnUt-AlK5PEED( INDpX ) )  ; 
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--  necilan  Slnnal  selection 


VLTc._il_SE».'snhS(CP_STE_SIGNALis,  1,  4,  CP-STK_*tP)  ; 
VuTt_lL_ScNSnAS<P_STF_MGNALS,  2.  4,  P_STK_MEU)  ; 
VwTE_IL_St*»SOKS(AVG_AUA_SlCNALS(  3,  4,  AVG_AOA_AED) 
VOTt_U  _SENS0AS<»_RATe_SIgNAL4,  4,  3,  P_KATF_“ED) 
VuTL_lL_S£N jOhSCTAS-SlGNALS,  S,  2,  1 AS_NED )  » 


S,  2,  1AS_ME&)  » 


--  Median  Select  LiutPuts 


TL_eFD_Vl.Ct>_STirK 
IL-KFO-V I.P.STTC* 
IL_AEG_V1.AQA.mSrL 
IL_«EG_Y3.P_PATe 
IL_PED-V3.Th_AIkSPEED 


STirK_CIJtCP_STK_t*ED)  ; 
STICn_C**0(P_5Tn_HEG) 
AnA_SIGNAt.(AVG_AijA_MEP)  S 
ANG_hAlE_SiCrtAL(P_RATE_NEC) 
IAi_>,lGNALlTAS_NtP)  ; 


--  Comparator  Lome  Cnecss 


EhK.EAHLT_I.QGlCCCP_LTK_SIGNALS, 
EnK.f  AIILT_1.0GlC(P_STK_SIGf.ALS, 


CP_STK_NEP, 

P_STH_*ED, 


1,  4,  CP_ST*_COnP)  J 

2,  4,  P_SIK_CQ»M  > 


CnK_FAI)l.T_LuGlC(AVG_AuA_SlCNALS(  aVu.AQA.MED,  3,  4,  AVG_A JA_Cu«P )  ( 


GnK.FAllLT.l.OGiriP.PATE-SIGNALS, 
CtiK_FAULT_LuG  1C ( TAS-S 1GN ALS , 


for  InPEX  In  1..4 

loot 

IL_CPMP_V j.CP_ST«_VAU INDEX) 
IL-CONP_V3.P_STK_VAL( INDEX) 
IL_COHP_V3. A VG_AO A_  V  A  L  f INDEX) 
It  INDEX  <*  3  tnen 
lL_CnHP_V3.P_RAIF_VAM INDEX) 
If  1NOFX  <*  2  tnen 
TL_Cn«P_Vj.  XAS.VALCillOFX) 
end  It  J 
end  It  ; 
end  loop  ; 

CnNu_3_XCrtF_NUM  :=  b  ; 

XCHF_SYNCli_J  J 


P-kAIE_NtD,  4,  3.  P_RATE_COnP)  J 
IAS_PED,  5 ,  2,  TAS_Cu*P)  I 

Comparator  vailqlty  Output 


:=  CP_STK_COPPC INOFx)  i 
:  s  p_stk_COnP  1 1 NPt  x  j  i 
:s  AVG_AOA_CO«P( INDEX)  ; 

IS  P_HATE_CO*P(I«DFX)  ; 

:=  TAS_CO*P( INDEX)  ; 


N-verslor  voting 


end  *<A‘:AGfc_lL_SENSnKS_Vi  ; 
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I 

i 

i 


Hac<o>ie  CH'.(-)-IL_vriTFK 


oaCKage  CmNL-A-IL-VUTER  is 

NL»_SeN50KS 

Nu*«»VuTtS 

SeT_ml“ 


INTECtR  range  2.. 4  j=  2  ; 
INTEGER  range  0..4  :=  o  t 
INTEGER  range  l..b  :=  1  ! 


t>oe  Bf1CI-_VtrTnH 
tyre  kFAI. vector 


is  array  (Integer  range  <>)  nt  o'jUJn  ; 
Is  array  (InTeGER  range  <>)  of  E  t.  «_i  A  x  ; 


y  Tu-COPP. COUNT 

I  tL-M.AG-Cot'NT 

IL-r'LAG-IN 

ru-ConP-OuT 


array  (1..S,  1..4)  of  INTeGEP  r<,nge  0..17 
;c  (others  =>  (others  s>  01)  } 
array  O..B,  i..«)  of  INTEGER  range  -S..5 
is  (others  =  >  Cotners  =  >  o)j  ; 
array  (1..S,  j..«)  of  boolean 

:=  (otrers  =  >  (others  =>  (RuE) )  ; 
array  (1..5,  1..4J  of  boolean 

:*  (others  =>  (others  =>  TRUE))  l 


orrceaurr  ChECK-tu-E LaOS( lt-ELAus  :  In  booL-VeCTOr  ;  SET-NUR, 

NI/N-SFNSlBL  S  m  INTEGER)  S 

orocegure  V0TE-1L.SE*I1>0RS(  TL-SEN50R5  S  in  ReAL-VECTUR  ;  SeT_Ni>R, 

NON.SENiCKS  :  in  INlEtiFh  ;  IL-SENSOK-.REi)  :  out  ELLA  r  1  1 

oroceoure  CmI'.EAHLT_LOGXC(  IL-SENSORS  :  in  REAL-VECTOR  1  IL-SEnSUR-PED  : 
In  FLOAI  ;  SET-NUN,  NUP-StNiOhS  I  In  INTEGEK  ; 

IL-CnRP_VAL  I  out  BU0L-VECTOR)  } 

end  CHNL-J-II. -VOTER  » 


» 

'  *4 


I 


■'M 


l 
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5: 


a 


panta-j*  t?op*y  CHni— 3.tL_mTFK  is 


prcceanre  rMFCK_TL_t  t.AGSf  II._flagS  :  in  anoL_VECTOR  ;  sEI-nUn, 

NUH-SFNSGRS  :  in  INTEGER)  is 


neoin 

for  i..ntx  in  i . . ru"_SENsnhS 
loop 

ease  I L-FLAG-COUNTt SFT-NUH ,  INDEX 
"nen  0  - > 

if  il.flagsi index)  =  FALSE 
men  I  L-FLAG-OQUNT  t  SET-NUN,  , 
end  if  l 
■nen  1 . . 5  => 

if  IL-FLAGSf INDEX)  =  FALSE 
men  IL_FLAG_CUtlNT(SET_NDN,  , 
IO_FLAG_raUnT( SET-NUN , 

It  It_FLAG_COUNT(SFT_i 
t nen  Xt._FLAG-iNiSET.NUR 
IL—FlAG— COUNT  f SE1— I 
end  If  ; 

else  I L— FLAG— OUtlnT C StT-NU* , 
end  if  > 

•  nen  *> 

if  IL-FLAGo(XNuFA)  *  TRUE 
men  IL_FLAG_rOHNT(SET_»'UR, 

T L— FL AG— OijUNT (SET— NU*  , 
It  IL_FuAu_COUNl (SET— l 
men  XL_FoAG.iNlSET.NUN 
XL— FLAG— COUNT  CSCI-l 
end  1 t  ; 

else  I L-FL AG— COUNT (SET-NUN, 
end  if  » 

•  nd  case  ; 

end  loop  ; 


INDEX)  :i  i 


••  feulieo 


XNUEX)  !S 
INDEX)  ♦  1  ; 

nun.  Index) 

,  index )  := 

NUN,  INDEX) 


>s  *> 

false  > 

:*  -l  ; 


INDEX)  SS  u 


neel in* 


INDEX)  !s 
INDEX)  -1  ; 
NUN,  INDEX) 
,  INDEX)  :* 

nun.  Index) 


<s  -5 
TRUE  ) 
:«  o  i 


INDEX)  :=  - 


end  CnFCK-IL-1 LAGS  ! 
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procedure  vuTt.il. _StNsni»S{  il_.sF,.Sups  :  in  Real.vECTjR  ;  StT.vuN, 

NUM.StNSPKS  :  In  INTFGFH  t  IL.SENSOH.NFp  :  out  FLuAT)  Is 

StT. Ranking  :  Jrrav  (  1 .  .  4  )  of  INTEGER  range  0 .  .  4  :  s  C  U ,  Q ,  U,  0)  ; 

v  :  arrav  (1..4)  of  float  :s  (0.0,  o.J,  O.n,  o.u)  ; 

Ttep  s  float  :*  o.o  ; 

neoin 

NUN.VuTtS  Nt'H.SFNSOHS  ; 

for'l.lOt*  In  l  •  .NUN. SEASONS  •-  Nnlcn  Sensors  Voting 

loop 

It  IL_'"u*t'_CMirCsFl_hUH,  INDEX)  s  FALSt 
mer.  hUH.VOTEs  :=  NUn.vOTES  -  1  ; 

else  iEi.RANK ING( 1NDFA)  ;s  INDE*  ; 
end  it  j 
end  loop  ; 

for  Ir.rtx  In  l .  .ncjm_vcjTLS  --  nhicn  value*  Voting 

1  OOP 

for  N  L.NII  N  In  InOE*..4 
loop 

If  CHNL.NU**  S  SET. RANK  INC  iCrtN  L.NU  M  1 
tr.en  VCINUEX)  ;s  iL.SENSOKSCCnNL.NUN)  ; 
exit  J 
end  it  j 
end  loop  ; 
end  loop  ; 

case  N'  n.votfs  is  -•  sensor  Signal  votlnq 

•nen  0  =  > 

null  ; 

»nen  1  s> 

lL.SENSOP.HED  :s  VCD  l 
wnen  2  - > 

It  veil  <=  VC  2) 
tr.en  li  .SEnsOh.nFD  :*  V(t)  ; 
eise  I L.SENSOH.HED  S»  V12)  } 
end  It  J 
wr.en  3  |  4  s> 

for  I  In  1 . .NU“. VOTES-! 
loop 

for  J  in  iti , .nuh.voteS 
1  oop 

It  VCI)  >=  VCJ) 

men  iehb  ;i  v c i )  i 

V(i)  IS  V(J)  I 

VCJ)  :*  TEhp  j 

end  it  ; 
end  loop  ; 
ena  ioco  ; 

1L.SENS0H.NF0  ;s  VC?)  ; 

•  r.d  case  ; 

end  Vote. 1' .sensors  i 
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rr"CfOUri*  CnK-FAtJLT.r-UClC  l  IL.sENSORS  :  in  REAL-VECTUP  :  I L_SEnSuR_“ tD  : 
In  float  ;  SFT.Nl'N,  *tu*_stNaOfcS  *  In  INlEuFS  ; 

IL.CnNP.VAl  :  Oat  PunL.^CTOR )  is 


AmPL-LInIT 
"AX. Cl 


constant  array  (1..5)  of  ElOAT 
=  C  0.2.  0.2.  1.25,  l.o,  10.0)  ? 
constant  array  (1..S)  of  InTeGER 
1=  (6,  o,  8,  a,  1 o )  I 


--  Hulleo 


for  INDEX  In  l..SfcT_NUM 
loop 

case  lL.CUNp.cnoNTfSET.NttN,  INDEX)  is 

ar.en  0  =>  *■  Nomai 

It  aOS (IL.5tNSnH.NFL  -  lL.StNSORS ( I NDEX ) )  >s 
A"PL.LINIT(StT_NUe) 

rnen  iL.CUPP-CnUNTfSEI.NtlN,  INDEX)  is  1  I 
end  It  ; 

■nen  l.,lo  =>  *•  taalteo 

It  aosf lL.SENaOh.MEL  -  IL.SENsOHSC INDEX ) )  >  = 
ANPI._IINXT(SET_NUN) 

tnen  IL.CQep.CnUNT (SET. NUN ,  INDEX)  :* 

il-.CONP-CnuNTfsrT.ftitN,  It.DEX)  »  l  ; 

if  IL.CONP.CutlNTl.SET.NUN,  INDEX)  >*  NAA.CTiStT.NoMj 
then  iL.CONP.nuTiSET.NuN,  index)  :  =  KALSt  ; 

IL.CONP.COttNT  (SET. NUN,  INDEX)  1=  IT  I 
era  if  ; 

eise  IL.CjNp. count's El .NUN,  INDEX)  :*  o  »  Recovering 

end  it  ; 

wnen  IT  =  >  •“  Ealleo 

null  ; 
end  ease  ; 

IL.COnP.VAU INDEX)  !*  IL-CONP.OUTtSET.NU",  INDEX)  or 
IL.ELAC.INCSET.NUn,  INDEX)  ; 

end  loop  « 

end  Chr.r aiilT-LOCic  ; 
end  CrtNL.  i./'—VuTEP  t 
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Ada  Krocerfcre  CALG_TAVE»_rt.0P-ir3 


w  1  ?  n  UFCS.LuGIC 
»  1 1 n  OFCS.PLSLUkCES 
«lEn  iL.PE5uMKC£S 
•Itn  vOTING-PLAnES 
SeCdrdtefCGMT(-riL_LA«J) 
procedure  rALC-INNFK.LOUP.v j  is 


use  nfri.Lomc  ; 
use  OFCS.REBOLRCES 
use  IL-hEaOURCEa  ; 
use  VQTING.PLANES  ! 


type  SCHELUuE  Is  (HIGn,  H10.  L0»)  ; 

P.SlTC'.XEf',  CP-STrCK_«Ef',  TnT.aTXCK, 
P.BATt-HED,  AVG.AOA.NEO,  AOA.HP, 
TaSAEO,  UFL_t»a, 

A.SIICK,  K. ALPHA.  H.P.nAXE, 

IL.5TAB.00.  OL-SIAo-CHL.  IOX.aTAB.CND 

Srf  EP 

Tas.valxditx 


float  ; 

SCHtOJLc. 
BOOLEAN  i 


rei  lr 


--  Loti  versions 


B.sxrcK.Mto  :»  float ( i l.mfl.v  3 . p. stick )  .• 

PP-aTiO.MFD  ;a  KLOATlIL.eFD_y3.CP.STlClO  l 
P_°ATL.HEl>  :*  FLO AT(  T L.MED.V  1 ,  P_R ATE )  J 

AyG.AOA.etr>  ;*  FLOAT  (TL.*FL_V).A0»-D1SPL)  ; 

TAS.nkO  FLOAT ( 1 L.HFU.V 3 . TR.A I kSPEED ) 

TAS-VALXOXTif  i=  rL.COBP.VJ.XAS.VALU  1  and 
I L.COP.V 3.TAa_VAL(2)  S 


It 

tnen 


X  A  a— V  ALlLf  X*Y 


If 

men 
e  Is  t  £ 
men 
else 


X  AS-MEL) 

S°tEu 

XAS..SEO 

iPEFO 

SPlEL 


TKUfc 

>s  4S0.0 

: =  high  » 
<=  too.o 
j»  Low  ; 

: =  "X6  > 


-«  uiin  SctieHuliniy 


end  if  i 

else  SPtEL  HIGH 

; 

end  It  ; 
case  SPEF.u  is 

•  ntn  luw  =  > 

A.STICK 

s 

o.s  ; 

K.ALPHA 

= 

0.  IS  £ 

A-P.HAIt 

S 

0  •  2  # 

men  eiu  => 

OFl.IAS 

* 

rAa.efL 

K.STJCR 

o.so  - 

A. ALPHA 

S 

O.OS  - 

K-P.HATE 

= 

0.10  - 

men  HIGn  *> 

K.STICK 

3 

0.1  ; 

K. ALPHA 

3 

O.os  ; 

n.P.HATE 

= 

0. 1  ; 

end  ease  ; 

lOU.U  l 
DEL.TaS  »  DEL.A.SXICK  ; 
DfcL.TaS  »  DEl.K.ALPriA  ; 
ntL.TAS  «  DtL.K_P.RAU 
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if  abs  tP.sTKK.Mrbl  «.=  o.ni  --  Stic*  Blending 

f n»n  p.STi ca.mfp  :*  O.o  ; 

and  It  ; 

It  absfCP.STICF.MtP)  <=  O.Ob 
men  CP.srlc'K.etO  :=  0.0  ,* 

and  tt  l 

TLT.STICI'  :=  p.uT  1CK.MFD  ♦  CP-ST  ICK.MtD  ; 
it  absdni.sTiCK)  >  12.5 

tnen  if  TLT.S1ICK  >  1.0 

tnen  TuT.SITCK  :=  12. b  ; 

alia  TOT. STICK  .•  s  -12.5  ; 

end  If  j 
end  If  ; 

It  not  INITIALIZED  --  Alpoa  nljO-PoS» 

tn*n  ut.b.AVG.AnA.MFO  :*  AvG_AGA_MtD  > 

>.LS_A0A_rtP  5=  0.0  ; 

and  It  S 

Au».HF  ;*  AUAl_h»AV0_A0A_NED  ♦  A0A I.K M 1 •OLD-A VG_AuA_“tD 

-  A0A0.Kn1»0LD.AUA_HP  ; 

--  Inner  Loop  control 

IL.bTAB.CMn  :*  P.KATF.«tD  *  K.P.RATE  ♦  AOA.ilP  •  K.AlPhA  - 
TOT. STICK  •  K.STTCK  > 

If  MOUE.FhG.V3. AUTOPILOT  s  AUTOLAND  --  Outer  Loou  surname 

tnen  GL-STAb.CMU  ;*  -  0.35  *  FLOAT C  AUIOLA hD.CHD.V  J )  » 
else  Ol..STAt)_CMD  :=  0.0  ; 

end  it  ; 

TUT_5TAB_C"L  IL.5TAP.CM0  ♦  nL.STAB.CMD  ; 

If  TOT.STAB.CMU  >  1.0 

tnen  TQT_STAb.CMD  :=  1.0  j 

alSlf  TOT_SIAB.CMU  <  -8.0 

tnen  TOT.STAd.CMU  :»  -8.0  j 

end  It  ; 

S  TA  b.SEfi V0_C“D. V  3  :  =  STAB_CU“MAND t TOT_STAd_CuD 1  i  —  Output 

CnM,.J.XCHK.NUM  ;=  b  ; 

XCHK.SYhCn.J  J 

and  CALC-INNFH.LnOP.V3  I 


Packaae  lL_RtSQURCk.S 


car<age  TL,_r(F^nijPCEi>  is 


"e-T— K-SIICK 
rtL.X. ALPHA 
r£L_K.P.r<ATfc; 


rons^ant  FLOAT 
ror  s  t an  c  FLOAT 
'■urstanc  FLOAT 


o.4/3b0.o  r 
0.1/35>O.P  ; 
0.i/3b0.0  : 


Anoj.p-of -At  tack*  Hicrh-pass  Filter  Coeftlcierts 


AO  A  i_F 
AOA I_KW 1 
AOAQ.KM1 


constant 

constant 

constant 


6  0  U  .  0  /  b  °  1  .  j 
“oOu.l/bni  .u 
7°*.G/o°i .  0 


r-Ln-Avf:_AOA«Me.r,  Ul,G.AtiA_nP 
Tf.r  riALiZtO 
TL_RroFUDCFS  ; 


FLOAT  :=  o,(;  ; 

F  0  0  0  E  A  N  t  -  F  A  L S  c.  } 
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L'V&fcfc3K>? 


mn  mri  nr*  mnmr  mr*  *n  i  it  wmw  i/T  VTif?  r*  ir*F^  r~ 


4  3  t  'tj.dU  i  a-  *  .  w  j 


« 1 1  n  O'annFL-RES'IubCFS  ;  use 
*itn  vOTIsG.PLAnES  ;  use 

Seoarata(i}FCS_tuGIrl 
Procedure  AoSESS..jYoTEe_V 3  IS 


use  CHMHNfL-fiFSOUSCEi 
use  1<11  H.C_PLA(.Ei  ; 


<"r'-iTK_CT  ,  P.STK-CT  ,  *n*_CT, 

CaPTR.CT 

P_B ATE.CT 

TaS.CT 


1  f  CH>i  _S1  AT':S.<  1  =  Trtit 
fnen  C“PTk_ct  ;a  i  ; 
e  n  <1  It  ; 

It  C'H,<L_Sl*IUi_<2  s  Tmit 
t  r.en  CRpTu.CT  ;i  CapTe.CT  *  t 
end  it  : 

If  CHM..5  l»T'>a_w  I  *  T  ht't 
fv-n  (.«PTh_ET  :=  C«PTK_CT  ♦  1 
end  It  ) 

If  C***N— ' SfATJS-YA  3  Tnut 

tner,  0*PTA_CT  :  =  C«PTk_CT  ♦  1 
end  It  I 


for  1 N  o  E  A  In  1  . .  4 
LOOP 

if  tL-CneP.Vj 
t"en  rp.srr.CT 
era  if  : 

If  IL-CdfP.VJ 

men  p_5TK_rT 
ena  l*  » 
if  iL_cn«P.vj 
iL_cn*p_vj 
men  10*.  CT 
ena  if  ; 

if  INOfcx  <=  j 
U,.CneP_Vi 
t"en  p.RATE-CT 
ena  if  : 
if  INOtx  <s  2 
Ib-Cnnp.vj 
men  TAS_CT 
end  if  i 
ena  ioop  i 


:  INTEGER  range  n..i 
:  InTeGer  range  n . . j 
s  integer  range  n..u 

:  PoDLFaN  ;i  FALSE  ; 


Cnet*  L  *  U  Status 


.CP_STF_VAI.(INDEX)  *  TRUE 
:*  CP_STK_CT  *  i  ; 

. P.STK_*  AL ( i PUP* )  *  TRUE 

JR  P_aTA_CT  ♦  I  ; 

.LF.AUA.VAI (INDEX)  *  TRuE  ana 
.RT_A0A.VALIINDEX)  *  T0UF 
:s  AOA.LT  ♦  l  I 

an u  tnen 

.P_Mlf_VAI  l  INCEX  >  =  T»UF 
:*  r'_RAIE_CT  ♦  i  ; 

ana  tnen 

. ISO.YALt INDEX )  s  TRUE 
( 3  IAS_CT  ♦  |  ; 
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<-_k*Ti-_CT  i  i  anti  TAs.CT  =  2  --rnecK  Kb 

tnen  lC-On  :*  faiof  i 

It  aca.CT  i  ♦  ana  cmpth.CT  s  4  and 

(Cp.sTK.CT  s  4  or  rise  P.STK.CT  i  4  or  etse 
(CP.STK.CT  »s  J  and  P.STK.CT  >*  3)1 
tnen  t 8a_5TATbS_v  j  :=  Cp.STATt.l  ; 
elslt  AOA.CT  *  3  ana  CMP1R.CT  >*  3  and 

(P.STK.CT  >=  3  or  else  CP.STK.CT  >s  J  or  e 
(P.STK.rr  >3  2  ana  CP.STK.CT  >*2)1 
tnen  FR«_3TATUS_V3  :s  O P_STATc._2  l 
elsl  f  aOa.CT  >a  3  and  C»PTR_CT  b  1  ana 

(P.STK.CT  >*  3  or  else  CP.STK.CT  >s  J  or  t 
CP.STK.CT  >s  2  Bnci  CP.STk.CT  >32)1 
tnen  t Be.STATUS.V J  np_aTATE_2  ; 
elslt  AOA.CT  >3  j  and  C'npTk.CT  >s  3  and 

UP.STK.CT  s  3  ana  CP.STK.CT  <s  1)  or  else 
(Cp_s Tk.CT  3  3  and  P.STK.CT  <=  ! )  nr  else 
CP.STK.CT  =  2  ana  OP-iTK.CT  =21) 
tnen  FBe_5TATUS.V3  :*  0P.STATE.2  J 
else  CjC.cn  :=  true  ; 
end  It  ; 

else  uO.ON  ;=  TRUE  ; 
end  It  ! 

If  ciO.O*  =  TPtl  f. 

men  If  (AUA.ct  *  2  and  CPTa.CT  >3  2  and 

(P.STA.CT  >=  2  or  CP.STK.CT  >=  21  J  or 
(AOA.CT  >»  2  ana  CfSPTP.CT  a  2  and 
(P.STK.CT  >*  2  or  rp.sTK.CT  >s  2))  or 
1 AUA.CT  >=  2  ana  OiPTR.CT  >s  2  and 
UP.STf._CT  3  2  ana  tnen  CP.STK.CT  <3  11  or 
j  (P.STK.CT  <*  1  ana  tnen  CP_ST*-Cr  «  2)1) 

tnen  t  r«_StaTUS_vs  ;  *  ap.4TATt._3  ; 
else  FRa.4TATciS.V3  S»  0P.STATE.4  I 
end  if  ; 


--rnecK  Fb*  Status 


or  else 


tnen 
else 
end  1 f 
end  It  I 


case  FBa_ST«TUS.V3  IS 

■nen  OP.SrArE.l  I  0P_4TATt_2  => 

FLY.0UAL.V3  S3  NUPRAb  ; 

■nen  UP.STA1F_3  I  CP.STATt.4  => 
If  P.NATF.CT  >3  2  and 


--  CnecK  Flying  c.uallt» 


AOA.PT  >3  2  ana 


1AS.CT  x  2  ana  CT.STk.CT  >b  2  Or 
tnen  FLY.QUAL.V3  :*  normal  ; 
elslt  (p.Pate.CT  <*  1  or  TA5.CT  <=  11  ana 
ACA.CT  >s  i  ann  (P.STK.CT  >»  2  or 
tnen  HY.OUAL.VJ  |3  DtOHAOFD  ; 
elslt  P.NATF.CT  >3  2  ana  AOA.CT  <=  1  ana 
(P.STK.CT  >3  2  or  CP.STK.CT  >=  ?) 
tnen  FLY_UU«L_V3  5=  Na»lYnAl  J 
else  FLY.UUAL.V3  !■  UhFLYABcE  ; 
ena  if  ; 
end  case  1 


Cp.oTK.cT  >3  2) 


CP.S3K.Ci  >s  21 


ChNL_3.ACHK.N0>'  is  7  } 
YCNK.SYNCh.S  ; 


end  A5SES4.SYSTEN.V3  1 
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4ua  I'rocjunr*  UiVi.a4KMku.ki 

»l'n  vnT  I  iiG.plaivf.s  i  uif  VuTinl.pi  A*its  t 
■  ltn  ■AKNlMG_CHt'‘KS  I  IIS*  WAPMhG.ChFCFS  ; 
stnardfil  uFcs.LoGIC) 
pmcfiiute  Gxvl_.akninl.v3  is 


cas*  FLASH.WABNthG.Vj  Is 
»n.n  OFf  i> 

it  AL_«AkN_Vj  <z  CAT. 2. X  NUP 

ct-er  wapn_V3.ajtci.apc  :=  AL.WAPh.v3  » 

PUP. FAULTS  :=  1  { 

flash.wapn1hc.vj  •=  blinking  ; 

ero  if  : 

case  FbW. status. v 3  Is 

•  nen  OP.STAif.i  x> 

null  ; 

•  nen  gp.statf.?  x > 

wARh_VJ.FLY_PI_.IKF  !z  UP.5TA1 
FLASH.  WA»MhG_VJ  t=  B  L  I N  K  T  h 

huh. faults  :z  xnifgfk 

•  nen  lp.STAtf.3  s> 

WAPI..V  3  .  FLY.PI.x  THE  !x  LP_STAT 

FLASH.WAPhIhC.V3  !  =  bLINkTn 
NUN. FAULTS  !Z  IKTFGFK 

•  n*n  UP.STATF.4  z> 

HAPh_VY.FLY_PY_.IKF  :s  OP.STAX 
FLASH. WAPNTNG.VJ  :  x  bLXNM„ 

"UN.F.MLTS  :=  XN1EGFR 

era  case  > 

If  FLY.QLAL.V3  < x  DEGRAPtf* 

trer  • apn. v 3 . FLY Inl.LUaL  :p  I>»PA  iPtn.Fw 


■  -  hC*  Kdult 


-  UP.STATF.2  ?  —  he.  Hull 

=  BLINKING  ; 

*  INIFGFk*SUCClNuN.cAULTs)  ; 

-  LP.STATF.3  I  - -  he.  fault 

p  blinking  : 

=  IN  IFGFK  '  Slice  X*lu“ -Faults)  ; 

=  OP-STA IF. 4  ;  ..  he.  Fault 

p  bUNM.C  ; 

=  XNIEGFR'SUCGiNUM.FaUlTj)  > 


steady  : 


NUN-FAULTS  !«  INTECFB'SIICC(NUN.FAUuTs)  / 

FLA5H.WAPNIhG.V3  S*  BLINKING  ; 

era  If  j 

■  nen  BLINKING  =  > 

if  ACFhC.LtnGF 

then  flash. wAPhlNG.V 3  :=  STEADY  :  --  F.uitis) 

ena  If  » 

LBC  ATF. STATUS  f  At. .HAPh.V  3,  M3._STATUS.Vj,  FLY.OUAL.vJ, 
.AHN.Vj,  FLASH.WAPhlNG.V3 )  ; 

•nen  STlady  z> 

UPuATF.STATUS  C  AI..WAPN.  v  J,  fP._STATUS.VJ,  FLY.CUAL.V  3  , 
.AHN.Vj,  FLASH.WARNlhG.V3)  ; 

ena  case  ; 


a  * .  fault 


Fauitts)  hoteo 


GnNL.J_kCHK.NUH  :x  b  ; 
<CHf,_SYLGn_J  ; 

•  ne  GXVl_«akning.v 3  ; 


**  Call  lor  N*ver»Iun  Vote 


Figure  A- 14  Procedure  GIVE  WARNING  V3 


LOv'/hO/.vVV.-. 


■  •  ■  -  -  *  *  *j  *  *  V-  -j  -j,  - j,N 


A-37 


■  *  jr» Jn^nomy  WB)r?\H  ’ML’MWHflU.'VJ 


Paocag.  naRMnC.CmFCKS 


►ifn  ofcs. logic  :  use  lfcs.lqGIc  ; 

nacxage  warn rNG.CaFCKS  1* 


NUN-FAULTS 


:  T NTLGtB  range  0..j  :=  0  ; 


nj-ocegure  UPOATt_oTATjSlAL_«AFH_V3i  in  AL.S  1  »T''S  :  F0w_S  l  A  lLa_  «  3  : 

In  PBI.FCS.STATUSJ  f  L  T.QM  AL_  V  J  :  In  FLi  Il,G_3LALl  1  TlS; 
*Afit._v3:  in  our  xABninC.STA  tF  ;  FLA3I‘-«AB,,  T  nG.V  j  : 

out  »ASIEf_»AFN j  ; 

ml  NAPNlNC.ChFCKS  ; 

oacnage  body  warn ING.CHtCKS  Is 

orocejure  UpnATE_STATuSlAL_.AFN.VJ:  In  AL.STATUS1  Fb*_Sl  a  IU;>_»  3  ;  in 
PHI-FCS.STATlii;  FLV.0UAL.V3:  in  FL  V 1  NO-  JU  AL  IT IFS  1  .AH|,_«); 

ID  out  NAfNINC.STATI.  1  FLASh_.AFN[NO_V3:  out  NASTt»_»APN)  is 

real  n 

If  FABn.v  l.AUTuLAND  =  FLANK  and  tnen 

*L_«afn.v3  < e  CAT.^.inoP 

then  FLAiH.WABHlNG_V  J  !s  bLINMdG  I  --  N».  u«ll 

iu«. faults  ib  iNiFoFK'siicctNuM. faults)  ; 

elslt  •AkN.v3.A'iTCLAt,n  <s  cat.v.INUP  .no  tnen 

AL_.ARK.VJ  x  bLANK 

tnen  waBh_*3,AUTuLAN0  la  bf.ANK  ;  --  nne  Fault  Heamg 

‘U'-FAULTS  la  INTELFK'PKEDCNuN.FaULTS)  ! 


If  FAPh.V 1. AUTOLAND  =  FLANK 

AL_.AFN.V3  < e  CAT.i 

tben  fl»5h.uabhInG_V 3  :s  bL INF 

nun. faults  ib  inifl 

elslt  .‘RN-V3.A'iTCLAr,n  <s  cat.2 

AL_.AFF.VJ  x  bLANF 

tnen  NAPn.v  3 .  AUTuLANO  la  bf.ANK 

* UN.FAULTS  la  INTEL 

ft  AUN.FAuLTT  x  0 

tnen  f Las«_.afn iNg.y 3  :s  OFF  ; 

end  11  i 
e"U  if  ! 

If  FABn.V  3 , FLY.Bf_.IKE  a  bl  ANK 

Fo»_SlATUS_V  3  =  OP. ST 

tnen  «A9n_» J . FLY.RT.. IfF  :s  OP.ST 

FuASH..ARNlNG_vj  :s  bl  Ink 

Nu». FAULTS  :*  INTFu 

elslt  .ARN.Vj.FLi.bY.wlBt  > x  OP.ST 
Fu«.s  1  A  ri'S. V  3  X  OP.ST 

men  «A»l..VJ.FLY_PT.xlFF  :s  OP.ST 

P  L  A  s  N.  .  A  B  ,N  I G_  V  3  la  oLINn 

n  um  _r  A’’  LTS  :  a  l«TrL 

elslt  .AFN.v J.FLV.oY.NiBt  >a  OP.ST 
f3._STATU5.* J  =  OP.ST 

me-  «i°n_v 3 . fly.pt.. Iff  :i  op.st 

Fl*LH-FAB|(I..G.V3  la  6LI“K 

’-UN. FAULTS  ;x  INTFG 


--  All  raults  Re  a  1  no 


s  bl  ank  and  tnen 
=  OP.STATF.? 

1  a  OP.STATE.2  : 

:a  bl InkTNG  t 

:a  INTFuFF'SUCCtNuN.F.ULTS) 
>*  OP.STATE.2  ana  tnen 
*  OP.STATF. 3 
IS  OP.ST  AT  E.3  : 
ta  bLINnlNG  • 

:  a  INTFlFf  *sncClNu«.FAt.'LTj  ) 
>a  CP.ST‘TF.3  an0  tnen 
=  OP.ST  A  TE.4 

la  up.statf.a  : 
la  BLI“Kri,C  : 

la  INTFGEF'SUCClNuN. Faults) 
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elstt  kN.V  j.FU_BY_Wl»K  <=  QP.STAl E_2 
tnen  cost  Fn«_STATljS_v J  is 
wr.en  UH.STAIE.l  *> 

».*HN_V3.FLY_aY_HIPt  S=  BLANK  ;  --  One  Fault  Healed 

NHH.FAUI.TS  :=  TNTECES'PHFDf  NUH.FAULTSJ  ; 

if  KUW.FAULTS  S  0 

then  FLASH. BAPNlNCI.Vi  ;s  OFF  s  --  All  faults  Healed 

end  if  ; 

•  nen  CP.STATE.2  s> 

If  HAHN_V3.FLY_RY.atHE  s  OP_STATF_3 

men  VAPN_V1.FLY_RY_*?KE  :=  0P_SIATF_2  : 

eni  if  : 

If  ■VAPN_V3.FLY_BY_.itRF  s  uP_ST*TF_4 

tnen  «vAPn_V3  .  FLY.S  Y_«i  tRE  t-  UP_STATE_2  t 

end  If  1 

•  nen  uP_5TAYE_3 

If  ■ARN_V3.FLY_RY_aTRF  «  0P_S1ATF_3 

C nen  *APN_V3 . FLY.R Y_« IKE  : =  OP-SIATE.J  ; 

end  If  ! 

■  nen  CF.STATE.A  => 
null  f 
end  c««e  ; 
era  if  I 

If  HAPN.VY. FLY IKu.wU At.  S  bt.AHK  and  tnen 

FLY_OU  AL_V  3  <-  LFLPAOtO 

tnen  FLASR-HARfYlNG.v 3  .•*  BtlVAlNO  ;  **  «e»  Fault 

HUH. FAULTS  !  =  INIECFH'SUCCCNLH-FAULTS)  ; 

elslf  *"hn_V3.FLYING_QUAL  <=  IHRAlPtD.FO  ana  tnen 
FLY.OUf.L_V  3  s  NORKAL 

tnen  hapn.V 3 . FLYINU.OUAL  1*  bLA  Na  ;  —  one  F.uit  Healed 

‘lUX-FAULTS  !=  INTEGER  'RREDtNUM.FAULTSl  i 

it  Nim.FAotis  »  o 

tnen  F LASh_«arninu_v 3  :»  OFF  ;  --  All  Faults  Heaieo 

end  li  ; 
e"u  If  J 

end  UprATL.STATUS  J 

end  ■af,.TnG_ohecks  ; 
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